From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15437 invoked by alias); 27 Nov 2004 05:27:11 -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 15420 invoked from network); 27 Nov 2004 05:27:07 -0000 Received: from unknown (HELO urk.execulink.net) (199.166.6.45) by sourceware.org with SMTP; 27 Nov 2004 05:27:07 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp8.ac3.56k.execulink.com [209.239.3.8]) by urk.execulink.net (8.11.6/8.11.6) with ESMTP id iAR5Qxt21854; Sat, 27 Nov 2004 00:26:59 -0500 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id iAR5KDf09630; Sat, 27 Nov 2004 00:20:13 -0500 Date: Sat, 27 Nov 2004 06:07:00 -0000 From: mskala@ansuz.sooke.bc.ca To: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Image scaling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01441.txt.bz2 Okay, I had planned to go get a SourceForge account today, but that didn't happen; it's likely to be Sunday or Monday before I do, but whenever I do manage it, I'd like to go ahead with the making-a-CVS-branch idea. I've been through the scaling code, and it seems to me that it'll need a fair bit of rewriting just to get into a state where I can do things with the map terrain ideas. The basic idea is that you're supposed to be able to specify one or more images of varying resolutions, and the system will automatically choose the one that matches its requirements, or scale one of the specified ones to match any needed resolution you didn't specify. The "cut an image into hexes and apply it to the terrain" idea pretty much requires that this behaviour work correctly, because the image can only be at one resolution - trying to coordinate several versions at different resolutions would be a nightmare for the game designer and really break the convenience that was supposed to be the point of the exercise. There are some problems with the existing code, though. For one thing, it can only ever scale an image by a factor of two up or down - so if it needs two resolutions that are separated by a factor other than two, there's trouble. And in fact, the resolutions it does need are 1, 2, 4, 13 (!= 4*2), 26, 48 (!= 26*2), 96, 192 (so the code claims... I've never seen a 192-pixel hex)... and so there's trouble. If all you specify is one image and it's bigger than 16 pixels, then the smallest sizes will just appear as black, because the scaling cuts out when the result is below 8 pixels. And if you attempt to fix that by specifying a default flat colour, then *no* scaling will be done at all, and the default flat colour will be used for all unspecified sizes, which explains the annoying behaviour I've seen of everything going to flat colour at the highest magnification in some games. There is also weirdness in the handling of "subimages", so scaling probably doesn't work even now with border and connection terrain (may explain some other misbehaviour I've seen), and it certainly won't work for my contemplated hexgrid image patches. The actual scaling algorithm used is somewhat weird, and there are comments in the code suggesting that the previous implementor wasn't satisfied with it but was treating it as "good enough for now". I think the best way to deal with the scaling situation is to just remove the existing scaling code altogether and replace it with a new scaler that would be closer to really right, and would work by picking the closest match (maybe some preference given to bigger images) among the designer-specified images, and then scaling it to *exactly* the desired size, not just the nearest power-of-two step up or down. What kind of resampling algorithm to use is a tricky question because we're pretty firmly limited to 8-bit colour; I would be happier if we weren't, but don't want to do the (much larger amount of) coding to change it. I think the thing to do is use a mode filter, that is, let the colour of each output pixel be the most commonly-occurring colour among the input pixels that map onto that output pixel. That seems to be what the person who wrote the comments in the existing code thought was the right thing to do, but left to later to implement. I don't think I want to attempt the *really* really right thing to do, which would be to convert to RGB, do a Lanczos-filtered scaling, and then convert back to indexed colour - probably better to leave that at least until such time as we're ready to make the whole works RGB, because the lossage from the simpler algorithm is less than the lossage from using indexed colour anyway. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/