From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24466 invoked by alias); 27 Nov 2004 06:07:48 -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 23896 invoked from network); 27 Nov 2004 06:07:34 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 27 Nov 2004 06:07:34 -0000 Received: from [192.168.181.128] (c-67-176-41-158.client.comcast.net[67.176.41.158]) by comcast.net (rwcrmhc12) with ESMTP id <2004112706073301400rdcqte>; Sat, 27 Nov 2004 06:07:33 +0000 Message-ID: <41A819A2.9050003@phy.cmich.edu> Date: Sat, 27 Nov 2004 19:52: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, xconq-hackers@lists.sourceforge.net Subject: Re: Image scaling References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01442.txt.bz2 mskala@ansuz.sooke.bc.ca wrote: > 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. Sure thing. I would prefer, however, to integrate any image-scaling or other low-level image-handling fixes directly into the mainline, as they become available. Once you are to the point of implementing your map terrain ideas, I will be quite willing to make a branch in CVS. Of course, if you feel you need the branch sooner (uncertain fixes, etc...), that is fine too. > 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. Completely agreed. > 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. I've seen both of the problems you describe. If you can fix them, (a) that would be really great, and (b) I would prefer to merge them into the mainline sooner rather than later. > 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". Welcome to the Xconq sources! :-) I've seen variations on that "slogan" in a few places myself. > 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 share your sentiments here. I know there are several aspects to this problem, but one of the aspects, image files, could be dealt with fairly easily, I think. We already require 'libpng' to build ParaGUI. If we made it a general dep for Xconq, I don't think it would be a big problem. It is pretty much ubiquitous in the Linux world, and I have already shown that it can be easily acquired and integrated into MinGW32 on Windows. And, with a little script, I could pass ImageMagick's 'convert' command over the entire 'images' directory, and all the GIF files could be converted to PNG. And, finally, some careful use of a script and 'sed' could batch change all of the ".gif" endings in the .imf files to ".png" endings; I suppose a Perl person could do it more efficiently than me, but it is not a difficult task in any case. The only other thing that would need to be done, would be to set up the "imfhook" or whatever the image family loader function is called, to suck all the goodies out of the loaded PNG struct and image array (presumably decompressed by a library call). But, I suppose this last point leads to another aspect of the problem: internal color handling.... > 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. Seems reasonable. Eric