From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31379 invoked by alias); 26 Sep 2004 19:01:07 -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 31368 invoked from network); 26 Sep 2004 19:01:05 -0000 Received: from unknown (HELO urk.execulink.net) (199.166.6.45) by sourceware.org with SMTP; 26 Sep 2004 19:01:05 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp103.ac2.56k.execulink.com [209.213.229.103]) by urk.execulink.net (8.11.6/8.11.6) with ESMTP id i8QJ13106150; Sun, 26 Sep 2004 15:01:03 -0400 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id i8QIvDM27084; Sun, 26 Sep 2004 14:57:13 -0400 Date: Sun, 26 Sep 2004 19:19:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7@sources.redhat.com Subject: Re: Terrain images proposal In-Reply-To: <41570273.5010509@phy.cmich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01257.txt.bz2 On Sun, 26 Sep 2004, Eric McDonald wrote: > This is what I had in mind as well. But, perhaps I misunderstood you, > when you were saying things about providing a starting position from > which source map images would be embedded into the area display. The > impression I had gotten from you is that you were interested in being > able to associate a whole region of cells (and not just one cell) with a > source map image. The problem that I saw is what if you have a source That is what I meant, but I expected you would specify a range of cells that could be completely covered by the image. XConq would not automatically choose the range of cells to match the image size, certainly not to apply the image to cells that the image doesn't fully cover. Trying to specify a cell to be taken from an image where the image does not completely cover the cell, would be an error; XConq might or might not be able to handle the error gracefully, but it wouldn't be the behaviour I intended people to use even if it was handled in some graceful way. > image that is about 10x10 cells and starts at, say, (1,1), and then you > specify another source image at, say, (4,4)? There is an overlap. From > which source image do you extract the cell image? Whichever one the designer specified last - just like properties and table entries. XConq does not maintain knowledge of all the images ever specified at a cell - it just maintains at most one image per cell and overwrites that as each new one is specified. The idea is that the cell only *has* one image; syntax might allow that one image to be specified more than once, but if you do so it's just for convenience, like "I want to use this image over most of the area, but override it at this cell, so I'll specify a different image in this small area that which I happen to have mentioned once already". > But, I had thought that you were suggesting that whole rectangles > (spanning multiple cells) simply be embedded into the map at given > coordinates. Based on your response, I think this is not what you > actually had in mind.... What I had in mind was that you specify a roughly rectangular region of cells (yes, it'll have wiggly borders because it's made up of hexes) so that each one of them is clipped from the image in much the way hexes are already clipped from images. Within that region it looks like a chunk of the image is seamlessly embedded, because the cells are clipped from seamlessly adjacent hexagonal areas in the original image. The region stops hard at the hex boundaries, though. Imagine that I'm building a tabletop wargame in meatspace. I start with a chunk of hex paper and a nice big photograph. I lay out a hex grid on the photograph and cut it into hexagonal pieces. There will be chunks around the edges where the edge of the photograph cuts through a hex, so I have some non-hexagonal chunks, but mostly I have a bunch of hexagonal chunks of photo paper. Now I glue the really-hexagonal pieces to the hex paper in the same arrangement they had in the original photo. I throw out the non-hexagonal chunks. I paint terrain into some other cells of my hex paper - the ones not covered by photo. I end up with a map that has a chunk of photograph in it, and also some non-photograph terrain, but only one of those or the other (not both) in any given cell. There's an area of the map that looks like a continuous photograph without hex boundaries visible, but that's only because I was really really careful with my cutting and pasting so that the seams don't show. Around the edge of that area, where the photograph cells abut the painted cells, it's up to me to do my best job with the painting to make the boundary look good - or else use a photograph that really covers the entire area of every cell of my map, to avoid that issue. Maybe there's more than one chunk of photo on my map, too, but for each cell I chose only one hexagonal piece of photo to glue on. Maybe I used rubber cement, and when I found that I wanted to glue a photo onto a hex where I had already glued a photo, I peeled off the old one, discarded it, and pasted the new one in place - last specified source overrides all previous specifications. What I want to do with XConq is something similar. For each cell, or maybe for each (cell,terrain-type) pair, I store "What photograph (image file) is this from, if any?" and "Where in that photograph is this from?". I also want to automate the cutting/pasting by having some kind of input syntax that says "Here's a chunk of cells. Take images for these from this area of this image file, and compute the coordinates to make them line up nicely. I expect that this image file will cover all the cells I told you to use it for; if it doesn't, that's my mistake and you may abort." -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/