From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18465 invoked by alias); 25 Sep 2004 17:32:42 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 18457 invoked from network); 25 Sep 2004 17:32:41 -0000 Received: from unknown (HELO gencom001.gencom.us) (208.45.97.81) by sourceware.org with SMTP; 25 Sep 2004 17:32:41 -0000 Received: from localhost (localhost [127.0.0.1]) by gencom001.gencom.us (Postfix) with ESMTP id 7926F6355; Sat, 25 Sep 2004 10:50:30 -0700 (PDT) Received: from gencom001.gencom.us ([127.0.0.1]) by localhost (gencom001.gencom.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04943-06; Sat, 25 Sep 2004 10:50:30 -0700 (PDT) Received: from osts (home [67.171.201.213]) by gencom001.gencom.us (Postfix) with ESMTP id 78B6F6343; Sat, 25 Sep 2004 10:50:29 -0700 (PDT) Subject: Xconq Map Image Processing (WAS: GIS Tutorial Online) From: "D. Cooper Stevenson" Reply-To: cstevens@gencom.us To: mskala@ansuz.sooke.bc.ca, mcdonald@phy.cmich.edu Cc: xconq7@sources.redhat.com Content-Type: text/plain Organization: General Computer Message-Id: <1096133868.4973.17.camel@localhost> Mime-Version: 1.0 Date: Sat, 25 Sep 2004 17:32:00 -0000 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gencom001 X-SW-Source: 2004/txt/msg01240.txt.bz2 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