From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10757 invoked by alias); 24 Nov 2004 13:00:34 -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 10682 invoked from network); 24 Nov 2004 13:00:24 -0000 Received: from unknown (HELO s-hertogenbosch.execulink.net) (199.166.6.44) by sourceware.org with SMTP; 24 Nov 2004 13:00:24 -0000 Received: from diamond.ansuz.sooke.bc.ca (ppp49.ac3.56k.execulink.com [209.239.3.49]) by s-hertogenbosch.execulink.net (8.11.6/8.11.6) with ESMTP id iAOD0I125507; Wed, 24 Nov 2004 08:00:19 -0500 Received: from localhost (mskala@localhost) by diamond.ansuz.sooke.bc.ca (8.10.2/8.10.2) with ESMTP id iAO4qAk21463; Tue, 23 Nov 2004 23:52:10 -0500 Date: Thu, 25 Nov 2004 02:50:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Eric McDonald cc: xconq7@sources.redhat.com, xconq-hackers@lists.sourceforge.net Subject: Re: Thoughts on terrain imaging In-Reply-To: <41A40CF5.9020303@phy.cmich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004/txt/msg01437.txt.bz2 On Tue, 23 Nov 2004, Eric McDonald wrote: > > black. As far as I can tell, for some reason the automatic scale-down > > code isn't running. Isn't it supposed to? > > Yes, I thought so. I think it does with unit images. The bug may not be in the scale-down code, it turns out (althogh, as I said, there *are* plenty of problems with the scale-down code... this just might not be one of them). It seems to be in the TK stuff, and I'm probably going to be able to find and fix it myself. The general idea seems to be that there is an extra step that needs to happen to convert an XConq "image" structure into a "TkImage". I'm not sure exactly *when* that happens, because I've found the code that does it but not the code that calls that code, but the overall result seems to be that the conversion happens for explicitly specified cell-terrain images but not for ones generated by scaling. As a result, the code in tkmap.c gets all the way to the bottom, where it's about to draw the cell terrain, and then aborts (leaving black space) because the TkImage pointer is null. There is some kind of callback that gets set for doing the image-to-Tk (or, hypothetically, image-to-someotherinterface) conversion, so it may be that the scale-down code isn't calling that callback when it should, but the scale-down code *seems* to be calling it, so I think the problem may really be that the callback isn't doing its job when called; possibly because it's already been called before, when the explicit images were loaded, and it sets some kind of flag incorrectly telling itself "I don't need to run again" - but that's only a guess as to what's going on. > I played around with 'maptest.g' for a little while. If you reduce the > image cutout size down to 44x48 and change the subimage selection > offsets to 44, then the subimages show up at normal resolution. It does > not appear to matter whether the 'terrain' keyword is used or not. Yes, and the scaled-*up* images (88x96 generated when you only specify 44x48) seem to work, so the problem seems to be specific to scaling *down*. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/