public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* Xconq Map Image Processing (WAS: GIS Tutorial Online)
@ 2004-09-25 17:32 D. Cooper Stevenson
  0 siblings, 0 replies; only message in thread
From: D. Cooper Stevenson @ 2004-09-25 17:32 UTC (permalink / raw)
  To: mskala, mcdonald; +Cc: xconq7

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2004-09-25 17:32 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-25 17:32 Xconq Map Image Processing (WAS: GIS Tutorial Online) D. Cooper Stevenson

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).