This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GIS Tutorial Online


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]