Re: Terrain images proposal

[Eric McDonald <mcdonald@phy.cmich.edu>]

mskala@ansuz.sooke.bc.ca wrote:

> * associate with each cell of the map an optional "override" image name
>   and x,y coordinate.

This sounds nearly identical to the proposal for two new optional layers 
that I made yesterday. The only possible difference that I see is that 
you seem to be suggesting that a source map image name be associated 
with each hex (cell). Is there a need to have multiple source map 
images? Or, can we get by with a GDL global that indicates a single 
source image, and thus not have to associate it on a per hex (cell) basis?

> * when looking for the image for that cell, first check whether there is
>   an override; if so, look in the specified image *at* the specified x,y
>   coordinate

Probably hexes (cells) in the proposed image coords layers could be 
flagged with -1, if no override was in effect.

> * new subform of "area", which takes as input an image name and some x,y
>   coordinates specifying a starting point in the image and in the
>   map.  When this is specified it overlays the map cells on the image,
>   computes the x,y coordinates of each cell in the image, and sets the
>   override coordinates accordingly.  The result is that the image appears
>   on the map in that region instead of the auto-generated hex grid cells
>   that would otherwise appear.  Note that the image has not been processed
>   except maybe by being converted to GIF or whatever - it isn't pre-cut
>   into hexes and re-arranged.  Note that this subform could be specified
>   multiple times, so that you could re-use the same customized image in
>   multiple parts of the map and/or only customize an image for part of the
>   map while sticking to auto-generation elsewhere.

I am not sure how well a rectangular region of arbitrary size (if I 
understand you correctly) would mix into a sea of hexes. I think that, 
if anything, you would end up with a region looking like a postage stamp 
or a picture that was cut with the scissors that have "teeth".

> I think that would be pretty simple to implement and I'm willing to try if
> people would like me to.  

If you see the way and have the will, then go for it. By all means.

>An issue I forsee is what happens when terrain
> changes during a game.  One solution might be to simply blow away the
> "override" values as soon as the terrain changes in a cell; then the
> designer, if they're going to allow terrain changes while also having a 
> custom image map, had better provide default images that will look good 
> combined with the custom map.  

Agreed.

>Another possibility might be to make these
> overrides be per terrain type; that mixes badly with per-cell terrain
> types, but if we had for each terrain type the ability to specify an
> "override map image" then the system could show the appropriate slice of
> the large image for each terrain type.

The existing 'imf' form already allows for extracting arbitrary pixel 
positions from an image file and associating them with an image for use 
by Xconq. See, for exmaple, 'lib/pg.imf'.

Eric