From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23438 invoked by alias); 8 Aug 2004 01:02:54 -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 23431 invoked from network); 8 Aug 2004 01:02:53 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 8 Aug 2004 01:02:53 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc13) with ESMTP id <2004080801025201500nrfmae>; Sun, 8 Aug 2004 01:02:53 +0000 Message-ID: <41157BB9.50508@phy.cmich.edu> Date: Sun, 08 Aug 2004 01:34:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: Hans Ronne CC: xconq7@sources.redhat.com Subject: Re: IMFApp Office References: <200408051452.i75Eqlg06099@panix5.panix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00850.txt.bz2 Hans Ronne wrote: >>With the Linux/X11 Imfapp, the images from 'wreckreation.imf' appear >>strangely in the 32x32 menu tiles, but the closeup views seem to be >>fine. Any idea why that might be? > > This is because your images have non-standard sizes. I realize they have non-standard sizes, but that should not cause black patches to appear at various places around the images in 32x32 grid boxes (whereas there are no display problems with the scaled images in the 32x32 closeup view). > Xconq assumes by default that images fit within a 32x32 box (the "unit" > box). I found that rather restrictive a few years ago, when I added the > images for the advances and lord-rings games. These images were from > various Civ2 scenarios, and all fit within a 44x48 box (or to be more > precise, I made sure that they would fit within a hexagon of that size, > which is what the basic Xconq cell is. I saw the 44x48 images, and assumed that Xconq would scale the images based on that. The reason I chose a height of 64 is so that it would fit the largest view size without having to be scaled back up from 32x32. > The point of staying within one cell is that it makes the graphics much > more complicated (and time-consuming) if an image covers adjacent cells, > since these adjacent cells also must be redrawn when the unit moves. I'm not interested in drawing outside the cell. I had just hoped for scaling, and assumed it was there based on the 44x48 circumstantial evidence. > There is no support for this in the > current interface code. I hadn't tested out the images in a game yet, so I hadn't discovered that. > However, a further complication is during actual drawing, when best_image > checks that no image is greater than 32x32 (or 44x48) and scales the image > in that is the case. Your images, if used in Xconq, would therefore be cut > to half-size before they are drawn. This is what I want. But, at the largest magnification factor, shouldn't Xconq be attempting to draw actual 64x64's if they exist? > What you now > see is essentially the reverse of this, and indeed, if you click on one of > the images, click on the other, and then click on the first one, it is > redrawn at a smaller size which will fit within the 32x32 box. Right. But that doesn't explain where all the black crap surrounding them is coming from. > My advice would be to try to keep images within the bounds Xconq expect, > i.e. either 32x32 or 44x48. Well, I'll make them 32x32 now that I know how limited the graphics code is. > P.S. Another strange thing that you may have noticed is that your new gif > appears (distorted) when you select wreckreation in the new game list. Hadn't tested it. My copy of Wreckreation is still in mid-hack and not in a usable state. > So it is also a good idea not to name gifs exactly as an existing game > (unless you do want that gif to appear in the preview window, of course). I probably would have reached this conclusion had I seen the symptom you describe. Eric