public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
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

  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).