From: Eric McDonald <mcdonald@phy.cmich.edu>
To: mskala@ansuz.sooke.bc.ca
Cc: cstevens@gencom.us, xconq7 <xconq7@sources.redhat.com>
Subject: Re: GIS Tutorial Online
Date: Sat, 25 Sep 2004 17:32:00 -0000 [thread overview]
Message-ID: <415599AA.40201@phy.cmich.edu> (raw)
In-Reply-To: <Pine.LNX.4.21.0409250951520.18307-100000@diamond.ansuz.sooke.bc.ca>
mskala@ansuz.sooke.bc.ca wrote:
> 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. Even if I
> define a list variable for "all desert hexes", that's only a syntactic
> convenience - the actual game definition still has two separate complete
> copies of the definition. It's especially a problem because "two" in this
> case is probably more like "hundreds". I don't want to look at the help
> menu that will result from having hundreds, or thousands, of defined
> terrain types... 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.
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). I
have enough other things I plan on doing that I doubt I would
participate in such an endeavor, except to merge and test patches, and
provide feedback and guidance where I am able. I am certainly not going
to discourage either of you from working on the kernel and UI code.
> On multidimensional "binning", that's a well-studied problem
Sure, I know. And I only called it "boxing" because I thought people
might be tired of seeing me write "bin" or participles thereof over the
course of the last few days....
>and relevant
> to my research, so I'd be happy to expound on the different standard
> algorithms for it if people would like.
Good.
> 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.
I tried your original when you posted it to the list. I haven't tried
any updates that you may have made to it. I've been pretty busy just
trying to keep up with Elijah lately. :-)
>>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',
>
> 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.
This would be a useful feature. One could then envision ye olde time map
with a fancy compass rose, spouting whales, and sea monsters as part of
the background artwork. I would certainly be supportive of anyone who
wished to add such a feature.
Eric
next prev parent reply other threads:[~2004-09-25 16:16 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 [this message]
[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=415599AA.40201@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).