From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15602 invoked by alias); 12 Dec 2004 04:17:33 -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 15570 invoked from network); 12 Dec 2004 04:17:28 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 12 Dec 2004 04:17:28 -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 <2004121204172701400e8ge1e>; Sun, 12 Dec 2004 04:17:27 +0000 Message-ID: <41BBC642.7070605@phy.cmich.edu> Date: Sun, 12 Dec 2004 04:21: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: Reduced Image Quality for 32x32 Pixel Units References: <20041212011304.61237.qmail@web13122.mail.yahoo.com> <41BBB053.2030402@phy.cmich.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01475.txt.bz2 mskala@ansuz.sooke.bc.ca wrote: > 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. Excellent. I'll handle the interface side of things once you have the revised function ready. >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) Well, 'imfsample' might be the Tcl/Tk widget you are referring to. The function that I recently changed to deal with the crash was 'tk_u_image' or something like that. It simply looked up an IMF to use based on a name; it didn't have to do with scaling. Matter of fact, there is an array of IMF's ('uimages', IIRC) that is precalculated at some point, and the function returned an IMF out of that array. I need to find where that array is filled out, and I can probably nip some of the interface issues there. Speaking of 'imfsample': I believe it is a Tk widget. Under Windows, it likely has a device context associated with it. If 'imfapp' initializes 3000 or so of these things, that is probably eating up GDI handles (not to mention heap) like there is no tomorrow. I wonder if there is a good alternative way to implement its functionality. It might solve some of the GDI memory problems Hans used to gripe about. >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. Sure. Of course. > 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? That is a good thought. The third pair would also be handy if an image existed at both ends of the range; it could help decide which one to use. Since we are compiling as C++ code now, the third pair can probably be made optional arguments defaulting to -1, which would mean to pick the largest end of the range, when images exist at both ends or no image exists in the range: ", int ws = -1, int hs = -1". > Low-res pixel color problem = the issue of some terrain types disappearing > at the lowest magnification, right? Yes. Sorry if I caused you any alarm about a potential new bug. Eric