Re: Isometric images, sattelite images, and rotation

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

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