From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12273 invoked by alias); 12 Dec 2004 03:27:06 -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 12192 invoked from network); 12 Dec 2004 03:27:02 -0000 Received: from unknown (HELO edam.execulink.net) (199.166.6.57) by sourceware.org with SMTP; 12 Dec 2004 03:27:02 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl712.rba1.pppoe.execulink.com [66.203.188.207]) by edam.execulink.net (8.11.6/8.11.6) with ESMTP id iBC3R0c01404; Sat, 11 Dec 2004 22:27:00 -0500 Date: Sun, 12 Dec 2004 03:33:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Re: Reduced Image Quality for 32x32 Pixel Units In-Reply-To: <41BBB053.2030402@phy.cmich.edu> Message-ID: References: <20041212011304.61237.qmail@web13122.mail.yahoo.com> <41BBB053.2030402@phy.cmich.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01473.txt.bz2 On Sat, 11 Dec 2004, Eric McDonald wrote: > calls 'best_image_in_range' with w1 == w2 and h1 == h2. I started to > look at the logic involved, but got distracted by other things. I could > probably make the changes, but I would be much more comfortable if you > did, Matthew. I'll try building a best_image_in_range function in the kernel - that should be easy - but I'm not sure about the interface side of the equation. I think that there's a TCL command implemented for the purpose of requesting unit images (possibly even the same one you were looking at with those crashing bugs I filed recently) and that command will need its syntax changed or something to deal with the additional arguments, and then the TCL code that actually uses that command will need to be updated too. Presumably similar changes on the SDL side, although I'm even less sure of the details there. Now, if there isn't an image in the range and it has to scale, to what size should it scale? I'm thinking maybe it should go to the largest end of the range - it's going to look blocky for being scaled anyway, so it might as well at least be big - but would it be better to have a third width/height pair as well, to be the size to scale to if scaling is necessary? > as the yellow pixels problem and low res pixel color problems are fixed > before 7.5.0, I don't really care how long development goes on in a > special branch. Low-res pixel color problem = the issue of some terrain types disappearing at the lowest magnification, right? -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/