public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: "D. Cooper Stevenson" <cstevens@gencom.us>
To: mskala@ansuz.sooke.bc.ca, mcdonald@phy.cmich.edu
Cc: xconq7@sources.redhat.com
Subject: Xconq Map Image Processing (WAS: GIS Tutorial Online)
Date: Sat, 25 Sep 2004 17:32:00 -0000	[thread overview]
Message-ID: <1096133868.4973.17.camel@localhost> (raw)

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

                 reply	other threads:[~2004-09-25 17:32 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1096133868.4973.17.camel@localhost \
    --to=cstevens@gencom.us \
    --cc=mcdonald@phy.cmich.edu \
    --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).