From: Eric McDonald <mcdonald@phy.cmich.edu>
To: cstevens@gencom.us
Cc: mskala@ansuz.sooke.bc.ca, xconq7 <xconq7@sources.redhat.com>
Subject: Re: GIS Tutorial Online
Date: Sat, 25 Sep 2004 17:59:00 -0000 [thread overview]
Message-ID: <4155ABA9.5060606@phy.cmich.edu> (raw)
In-Reply-To: <1096130231.41559eb7e1508@mail.gencom.us>
sales@gencom.us wrote:
> Quoting mskala@ansuz.sooke.bc.ca:
>>I'd much rather be able to define images per-hex instead
>>of per-terrain-type; that seems like it would serve the same goal and be
>>much nicer.
>
> To me this makes sense. This would mean that map attributes are defined in a
> uniform array per tile. The _tile_ is the object. It then carries with it a
> number of attributes such as terrain type, elevation, climate, etc.
An individual hex only has certain attributes that can be associated
with. Among them, terrain type and elevation. As it stands now, images
are only associated with terrain types, and not directly with hexes. An
hex acquires an image via its terrain type. As far as other attributes
such as climate, terrain ruggedness, vegetation, etc... go, you must
find some way of artificially simulating those attributes. I suggested
one way (creating defined groupings in the game definition file), and
Lincoln suggested another (using coatings as sort of customizable
"attribute layers").
It should be noted that Xconq has the concept of layers, which were
mentioned in a references I sent you a while back ago. Layers track
things such as terrain, winds, coatings, connectors, borders, land or
sea, etc.... One can argue about what a Xconq map hex is, but one way to
look at it is something that has a coordinate position and has "depth"
into one or more layers. All hexes have depth into the terrain layer, as
this tracks terrain type and how is an hex is able to "know" what it
looks like.
> Does this mean major changes to the Xconq code, Eric? Would we have to change
> the Xconq kernel or could we get away with doing this on the module side?
I have made no attempt to quantify how much work will be involved. In
the reply I sent you last night (to your "cstevens" address and not the
"sales" address), I outlined some of the areas you will probably want to
look at. I think it is reasonable to assume that you will have at least
some coding that needs to be done in the kernel and the user interfaces.
>>It would be really nice, too, if that one file could be just the direct
>>image (possibly scaled to size), and then XConq smart enough to clip out
>>hexagonal chunks in the right places. That would mean changing the
>>read-from-image code to use a hex grid corresponding to the map instead of
>>the current square grid, but it would mean eliminating an especially nasty
>>cut-and-rearrange step in creating the file.
>
> I agree. This way if Eligah wanted to create his "Lord of the Rings" map, he
> could simply do so starting with a Middle Earth map
If people want to try doing things this way, it could probably be done
by creating two new layers (x-pixel-coords and y-pixel-coords), which
would contain the pixel coords within the map image that are associated
with each hex. Then, instead of indirectly accessing an hex image
through terrain type, it would be pulled from this layer instead. I
haven't thought through the details; _just throwing out an idea....
Eric
next prev parent reply other threads:[~2004-09-25 17:32 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
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 [this message]
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=4155ABA9.5060606@phy.cmich.edu \
--to=mcdonald@phy.cmich.edu \
--cc=cstevens@gencom.us \
--cc=mskala@ansuz.sooke.bc.ca \
--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).