From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1671 invoked by alias); 26 Sep 2004 16:01:51 -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 1663 invoked from network); 26 Sep 2004 16:01:50 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 26 Sep 2004 16:01:50 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (sccrmhc13) with ESMTP id <200409261601490160088uc9e>; Sun, 26 Sep 2004 16:01:50 +0000 Message-ID: <4156E7EB.9080705@phy.cmich.edu> Date: Sun, 26 Sep 2004 16:30:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) 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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01249.txt.bz2 mskala@ansuz.sooke.bc.ca wrote: > * associate with each cell of the map an optional "override" image name > and x,y coordinate. This sounds nearly identical to the proposal for two new optional layers that I made yesterday. The only possible difference that I see is that 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? > * when looking for the image for that cell, first check whether there is > an override; if so, look in the specified image *at* the specified x,y > coordinate Probably hexes (cells) in the proposed image coords layers could be flagged with -1, if no override was in effect. > * new subform of "area", which takes as input an image name and some x,y > coordinates specifying a starting point in the image and in the > map. When this is specified it overlays the map cells on the image, > computes the x,y coordinates of each cell in the image, and sets the > override coordinates accordingly. The result is that the image appears > on the map in that region instead of the auto-generated hex grid cells > that would otherwise appear. Note that the image has not been processed > except maybe by being converted to GIF or whatever - it isn't pre-cut > into hexes and re-arranged. Note that this subform could be specified > multiple times, so that you could re-use the same customized image in > multiple parts of the map and/or only customize an image for part of the > map while sticking to auto-generation elsewhere. I am not sure how well a rectangular region of arbitrary size (if I understand you correctly) would mix into a sea of hexes. I think that, if anything, you would end up with a region looking like a postage stamp or a picture that was cut with the scissors that have "teeth". > I think that would be pretty simple to implement and I'm willing to try if > people would like me to. If you see the way and have the will, then go for it. By all means. >An issue I forsee is what happens when terrain > changes during a game. One solution might be to simply blow away the > "override" values as soon as the terrain changes in a cell; then the > designer, if they're going to allow terrain changes while also having a > custom image map, had better provide default images that will look good > combined with the custom map. Agreed. >Another possibility might be to make these > overrides be per terrain type; that mixes badly with per-cell terrain > types, but if we had for each terrain type the ability to specify an > "override map image" then the system could show the appropriate slice of > the large image for each terrain type. The existing 'imf' form already allows for extracting arbitrary pixel positions from an image file and associating them with an image for use by Xconq. See, for exmaple, 'lib/pg.imf'. Eric