Re: GIS Tutorial Online

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

sales@gencom.us wrote:

> Now, one way to do this is to define a unique terrain type per tile. This, I
> think (and seems to be the consensus), does not seem to be the "cleanest" way
> to go.

I think it depends a lot on what you are trying to achieve. If you are 
planning on having more than one type of data associated with each hex 
(elevation, vegetation, terrain ruggedness), then it would seem that you 
would run into a multidimensional "data boxing" problem (which can be 
solved with multidimensional boxing routines that you would have to 
write) if you were trying to use less than 1 terrain type per image. If 
you only care about elevation data, say, then you can easily just bin 
the data according to elevation ranges, and thus don't need 1 terrain 
type per hex image. The alternative to multidimensional boxing is to 
have a 1:1 correspondance between terrain type and hex image.

I'm not sure what Matthew (IIRC?) had in mind when he disagreed with the 
1 terrain type per hex image idea. Maybe we are all miscommunicating 
what we really mean....

> It would be better, I think, to specify each tile as a file name (probably x,y
> such as 0x0.gif, 0x1.gif and so on) and have these images referenced by Xconq
> individually.

I have no problem with multiple files in an intermediate processing 
step, but all the terrain images for a given terrain image set should be 
kept in one file, when all is said and done. See 'stdt44x48.gif', 
'advt44x48.gif', and 'civt44x48.gif' in the 'images' directory for 
examples of what I am talking about.

Also, see 'terrain.imf' in the 'lib' directory to see how the various 
images are indexed within the files and assigned names.

> I know that Hans created and implemented a similiar patch that permitted units
> to have more than one image.

Right. There are several places you need to look to see how this was 
handled. A good starting pointing would be the properties files.
If you look in 'utype.def' in the 'kernel' directory, you will notice 
that the 'image-name' property is a list; you can tell this because it 
is a "DEF_UPROP_L" macro (the "L" is for "list"). By contrast, if you 
look in 'ttype.def', you will notice that the 'image-name' property is a 
string; you can tell this because it is a "DEF_TPROP_S" macro (the "S" 
is for "string").

Now, if you want to find out places where the 'image-name' property for 
units is used in the Xconq code, then you can just search the C source 
files in the 'kernel' directory and the various UI directories for 
'u_image_name', as this is Xconq's internal name for the property (as is 
indicated in the definition).

The other thing to do is search for 'image-name' in 'keyword.def'. This 
file enumerates all of the internal constants associated with GDL 
(Xconq's game design language) keywords. You will find that the name of 
the constant associated with 'image-name' is 'K_IMAGE_NAME'; you can 
search Xconq's sources for this to find out where and how it is being 
used. You most likely encounter it in 'read.c' and 'write.c', which are 
related to the reading in of Xconq games and the writing out of Xconq 
saved games.

A final note: IIRC, there are arrays that store the unit images (or at 
least their name lists/strings), so that they can be looked up and 
utilized quickly. One would probably want to do the same if one chooses 
this route for terrain images.

Of course, if one chooses to not bother with mutliple images per terrain 
type, then writing new Xconq code should not be necessary....

  Hope that helps,
    Eric