From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7814 invoked by alias); 26 Sep 2004 17:16:58 -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 7807 invoked from network); 26 Sep 2004 17:16:57 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 26 Sep 2004 17:16:57 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (sccrmhc12) with ESMTP id <2004092617165601200fmua8e>; Sun, 26 Sep 2004 17:16:56 +0000 Message-ID: <4156F985.8040100@phy.cmich.edu> Date: Sun, 26 Sep 2004 17:30:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: mskala@ansuz.sooke.bc.ca CC: xconq7@sources.redhat.com Subject: Re: Terrain images proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01253.txt.bz2 mskala@ansuz.sooke.bc.ca wrote: >>you seem to be suggesting that a source map image name be associated >>with each hex (cell). Is there a need to have multiple source map >>images? Or, can we get by with a GDL global that indicates a single >>source image, and thus not have to associate it on a per hex (cell) basis? > > My thinking was that someone might want to have a map which is mostly > generated from tiles in the normal way, but with a few small (in relation > to the map size) images pasted in in places where the tiling doesn't look > good enough. In such a case they might want to use two different source > images, although anything that could be done that way could also be done > by putting the data into one image and looking at different parts of > it. Part of my thinking was that it would be nice to not have to edit or > specially generate an image - if we could just use GDL to direct XConq on > how to cut chunks out of one or more existing images, then we have one > less tool to write or manual processing/editing step to do in defining a > game. The idea is interesting. The only problem is that Xconq has 4 different GUI's that "need" to be maintained. Supposing that you actually figured out a good way to implement your above suggestion, you would most likely end up writing the code 4 different times. (The "5th GUI", the curses interface, shouldn't cause too many problems, I think. :-) Another issue is "z-ordering". You would probably have to provide some mechanism so that the order in which redraws were stacked could be determined (not only can regular hexes and embedded images overlap with one another, but multiple embedded images can overlap with one another as well). > One concern I have about using a layer to specify x,y coordinates is that > then the data to go into the layer probably can't be manually generated, > so it means adding another tool to choose the x,y coordinates and put them > in that layer for XConq to read. Right. I think that with the present set of problems we are facing, there is no good solution that will come cheaply. Either we will end up developing external tools or we will end up doing some (potentially heavy?) hacking of Xconq. >If we could instead specify "start at > these coordinates, fill these many cells up and these many cells over, use > this step size" then it becomes something that we can manually specify, > at the cost of only slight complexity in the XConq code that reads that > specification. I think the more serious issues will occur in the display aspect of things and not the reading aspect. > Maybe we could use a layer and also add a "by-grid" or similar layer > sub-form to automatically generate the coordinates. That might address my > concern while still using an existing data structure. Yes, possibly. > Well, either you cover the entire map with your image, or else you already > face, anyway, the issue that your image has to match up along its edges > with the tiled terrain that it's going next to. If we allow some cells to > have image-overrides and other cells to not have them, then I think we're > going to get that issue in any case. True. Eric