From: Eric McDonald <mcdonald@phy.cmich.edu>
To: mskala@ansuz.sooke.bc.ca
Cc: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net
Subject: Re: Isometric images, sattelite images, and rotation
Date: Sun, 05 Dec 2004 02:24:00 -0000 [thread overview]
Message-ID: <41B2506D.7070902@phy.cmich.edu> (raw)
In-Reply-To: <Pine.LNX.4.53.0412041715470.11171@opal.ansuz.sooke.bc.ca>
mskala@ansuz.sooke.bc.ca wrote:
> But it gets worse, because the user can choose between six different
> angles for the isometric view. To get it really right we need six
> different images.
Unfortunately our CVS repo is already burdened with lots of images. I
would be loathe to increase checkout or update times any more than
absolutely necessary. (We can probably win back much space in the repo
and in the file releases, if we go from GIF to PNG, since PNG generally
achieves better compression.)
While I agree that having a stock of 6 different isometric images, plus
an overhead one, might be ideal, I think it places a large space burden
on the Xconq project, and another burden on designers of terrain tiles.
If we can avoid making this a requirement, I think we would be better off.
>That works because the existing
> terrain images don't really have much direction - they're basically
> textures and look the same whether North is the right place or not.
The Civ2 terrain images do have some direction-specific detail.
> If we're going to use satellite imagery, first we have the issue of
> rotating the clipped-out hexagons by 30 degrees to make them appear
> points-to-the-side, and then we're faced with the issue of rotating them
> into six different orientations as the view rotates, because the "North =
> 30 degrees counterclockwise of up" assumption only holds in one of the six
> orientations. If we have to precalculate all this we multiply the loading
> time for these terrain images by seven, not to mention the memory
> requirements and API/data structure issues, and I'm already concerned that
> the sheer number of terrain images is going to be too much just with
> loading top-down satellite imagery.
I share your concern with keeping too many images in memory. As I
mentioned to you when closing out your latest patch, we may want to
consider some sort of caching system and on-demand transforms. Only
transform an image when its corresponding orientation/projection info
does not match the current display orientation/projection. I really have
no idea about what sort of CPU impact this would have. This, if
feasible, would hopefully address both the storage space and memory
usage concerns.
> Possibly the easiest thing to do is just disable satellite imagery when in
> isometric mode, and demand that the game designer provide some reasonable
> default terrain images for use in isometric views. Thoughts?
I think that this may be wise in the shorter term. However, in the
longer term, I would rather get it "right", so that the end-user can
have a seamless experience without feeling like an isometric view is
inferior (in spite of the fact that it shows relief).
Eric
next prev parent reply other threads:[~2004-12-05 0:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-05 0:04 mskala
2004-12-05 2:24 ` Eric McDonald [this message]
2004-12-05 4:59 ` Elijah Meeks
2004-12-05 10:27 ` Isometric images, satellite " mskala
2004-12-11 3:58 ` Eric McDonald
2004-12-11 4:20 ` Attribute System Elijah Meeks
2004-12-12 1:13 ` Eric McDonald
2004-12-12 2:11 ` Reduced Image Quality for 32x32 Pixel Units Elijah Meeks
2004-12-12 2:43 ` mskala
2004-12-12 3:27 ` Eric McDonald
2004-12-12 3:33 ` mskala
2004-12-12 4:21 ` Eric McDonald
2004-12-12 4:17 ` Elijah Meeks
2004-12-12 19:05 ` Eric McDonald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41B2506D.7070902@phy.cmich.edu \
--to=mcdonald@phy.cmich.edu \
--cc=mskala@ansuz.sooke.bc.ca \
--cc=xconq-hackers@lists.sourceforge.net \
--cc=xconq7@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).