From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32158 invoked by alias); 12 Dec 2004 02:11:30 -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 32037 invoked from network); 12 Dec 2004 02:11:21 -0000 Received: from unknown (HELO edam.execulink.net) (199.166.6.57) by sourceware.org with SMTP; 12 Dec 2004 02:11:21 -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 iBC2BHc13189; Sat, 11 Dec 2004 21:11:17 -0500 Date: Sun, 12 Dec 2004 02:43:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Elijah Meeks cc: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Re: Reduced Image Quality for 32x32 Pixel Units In-Reply-To: <20041212011304.61237.qmail@web13122.mail.yahoo.com> Message-ID: References: <20041212011304.61237.qmail@web13122.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01471.txt.bz2 On Sat, 11 Dec 2004, Elijah Meeks wrote: > I've noticed in the new release of XConq that any unit > images based on a 32x32 size now appear chunky and > enlarged. I submitted a bug report at The issue, basically, is that the interface asks for images to be 44x44 (depending on the zoom level). If there is no 44x44 image, the kernel creates one by scaling. The older behaviour was to just return the 32x32 image as the closest match. One possible way of dealing with it might be to say, okay, 32x32 looks better than 44x44, so we'll make the interface request 32x32 instead of 44x44. That raises issues if the designer actually wanted 44x44. We've become accustomed to 32x32 unit images (even though the interfaces have actually been programmed to request 44x44); during my work on the scaler we already addressed one issue of this type by changing the Tcl/Tk interface to request 32x32 unit images in the unit type list pane. Another possible way of dealing with it might be to change the APIs so that the interface can request from the kernel "Give me an image somewhere in this range of sizes, and try to avoid scaling if possible." It's already looking like the API for getting images has to be made a lot more general anyway, to deal with issues like isometric/non-isometric terrain. At present, the kernel just has to kind of guess which kind of image the interface wants based on the dimensions, and there's Trouble if it guesses wrong. I'm starting to get a rough idea of what API changes need to be made. Maybe it'd be appropriate to do the CVS-branch thing, and/or wait until after the next non-pre release, because it's going to require across-the-board changes to both kernel and interfaces. FWIW, I actually like the blocky look of the scaled images, but I'm guessing I'm in the minority there. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/