This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Xconq Map Image Processing (WAS: GIS Tutorial Online)
- From: "D. Cooper Stevenson" <cstevens at gencom dot us>
- To: mskala at ansuz dot sooke dot bc dot ca, mcdonald at phy dot cmich dot edu
- Cc: xconq7 at sources dot redhat dot com
- Date: Sat, 25 Sep 2004 10:37:49 -0700
- Subject: Xconq Map Image Processing (WAS: GIS Tutorial Online)
- Organization: General Computer
- Reply-to: cstevens at gencom dot us
Matt:
>
> Just that it seems like it'll multiply terrain types unnecessarily,
and
> terrain types are somewhat expensive. If I have two chunks of almost
> identical desert, but they have different images, then I have to
duplicate
> the definition of "desert" throughout my game definition.
[snip]
> 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.
Coop:
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. You get a high degree of flexibility because each tile's complete
attribute set (including tile image) may be treated individually while
at the same time having the ability to assign similar attributes to
similar tiles.
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?
Eric:
In principle, I agree with you. I think that it comes down to the
question of whether you or Coop are up to hacking on Xconq to add the
necessary support, either more than one image per terrain type or
pulling an hex image directly from a map image (as you suggest below).
[snip]
I am certainly not going to discourage either of you from working on the
kernel and UI code.
Coop:
Okay. I think we're all on the same page with consensus and critical
support.
I would like my next step to be to create an algorithm that will
automatically lay a hexagonal grid over a map image and output the tiled
map data to a text file format containing a two dimensional array of
image tile data.
The image would remain a single image. I think I could "guillotine" the
image into "hex Chicklets" if necessary but would rather keep the image
intact if there are no "show stoppers."
Matt:
>
> By the way, has anyone tried playing the "standard game adapted for
> Antartica" module I posted? I'd be interested to hear how people
liked it
> if they tried it.
Coop:
Not yet. I've had my "head down" with the GIS stuff. I will this
weekend, though. You've inspired me to look at your dimensional array
code.
Eric:
One could then envision ye olde time map with a fancy compass rose,
spouting whales, and sea monsters as part of the background artwork.
Coop:
No doubt; Eligah would be in heaven :)
-Coop