From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15964 invoked by alias); 26 Sep 2004 17:30:29 -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 15952 invoked from network); 26 Sep 2004 17:30:28 -0000 Received: from unknown (HELO mailrouter3.execulink.net) (199.166.6.58) by sourceware.org with SMTP; 26 Sep 2004 17:30:28 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp103.ac2.56k.execulink.com [209.213.229.103]) by mailrouter3.execulink.net (8.11.6/8.11.6) with ESMTP id i8QHUQl05316; Sun, 26 Sep 2004 13:30:27 -0400 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id i8QHQav24977; Sun, 26 Sep 2004 13:26:37 -0400 Date: Sun, 26 Sep 2004 17:55:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7@sources.redhat.com Subject: Re: Terrain images proposal In-Reply-To: <4156F985.8040100@phy.cmich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01254.txt.bz2 On Sun, 26 Sep 2004, Eric McDonald wrote: > 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). What I had in mind was that each cell has only one override image, if any, and if it has one, that completely replaces the regular terrain image. So when XConq wants to draw the cell terrain in a cell, at present it looks up the cell's terrain type and then looks up the image for that terrain type. With my change, it would look for the image for that terrain type and that cell position; if there was one, it would use that, otherwise it would use the default image for that terrain type. If you attempt to define more than one override image for a cell position, that's either a syntax error, or the last one you define overwrites any previous one. Stacking order is never an issue - there is only one in the stack. It does become an issue for aux terrain, but it always was. If you attempt to define an override image for a cell that is "normal" terrain, that's fine, no problem, then it stops being "normal" terrain. If you tell XConq you are defining an override image for a given cell but the image you specify doesn't cover the cell, then (depending on implementation) that's either a syntax error, or it fills in the extra space with black or some other well-defined pattern, or it's undefined, and in any case, the solution is not to do that if you don't like the result. A critical point here is that the entire rectangle in the image would not necessarily appear on the map. When you tell XConq "take this cell out of this image" then that cell becomes a hexagonal window into the image, so unless you do that with a cell that goes over the edge of the image (and normally you wouldn't), you don't see the edge of the image. That's not so unusual, because it's the way that terrain images already work; you specify a recantangle in an image, but only the hex shape is actually visible. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/