This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Terrain images proposal
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