From: Eric McDonald <mcdonald@phy.cmich.edu>
To: cstevens@gencom.us
Cc: xconq7 <xconq7@sources.redhat.com>
Subject: Re: GIS Tutorial Online
Date: Sat, 25 Sep 2004 14:04:00 -0000 [thread overview]
Message-ID: <4154FAA7.7020504@phy.cmich.edu> (raw)
In-Reply-To: <1096084730.4154ecfabcb19@mail.gencom.us>
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
next prev parent reply other threads:[~2004-09-25 4:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-25 2:12 D. Cooper Stevenson
2004-09-25 4:57 ` Eric McDonald
[not found] ` <1096084730.4154ecfabcb19@mail.gencom.us>
2004-09-25 14:04 ` Eric McDonald [this message]
2004-09-25 16:16 ` mskala
2004-09-25 17:32 ` Eric McDonald
[not found] ` <1096130231.41559eb7e1508@mail.gencom.us>
2004-09-25 17:59 ` Eric McDonald
2004-09-25 19:24 ` D. Cooper Stevenson
2004-09-26 2:29 ` 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=4154FAA7.7020504@phy.cmich.edu \
--to=mcdonald@phy.cmich.edu \
--cc=cstevens@gencom.us \
--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).