From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2741 invoked by alias); 10 Aug 2004 19:02:10 -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 2729 invoked from network); 10 Aug 2004 19:02:08 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 10 Aug 2004 19:02:08 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7AIvHP6011894; Tue, 10 Aug 2004 14:57:17 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Aug 2004 14:59:36 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 0FBC870021; Tue, 10 Aug 2004 15:02:03 -0400 (EDT) Date: Tue, 10 Aug 2004 19:50:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com Subject: Re: IMFApp Office In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Aug 2004 18:59:36.0317 (UTC) FILETIME=[2E1C7AD0:01C47F0C] X-CanItPRO-Stream: default X-Spam-Score: 0.5 () X-Bayes-Prob: 0.9900 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg00861.txt.bz2 On Tue, 10 Aug 2004, Hans Ronne wrote: > >I see. It did seem that the display boxes were rather larger than the > >32x32 images being displayed in them. Since this is the case, shouldn't > >the "View" menu display sizes be listed as "44x48", "24x26", etc...? > > Perhaps. The big images started out as a oversized variants for some games > that I wrote, so I kept the old labels. But since the oversized images are > becoming more and more popular, maybe one should regard them as the > standard at some point. >From my point of view, the choice is simple and straightforward: (1) If a box is 44x48, and 32x32 images fit into it (I don't care if they are scaled up or not), then the view should be labeled "44x48". (2) If a box is 32x32, and 44x44 images are displayed in it by scaling them down, then the view should be labeled "32x32". Anything else is misleading. > >OK. Fair enough. However, the image that I did this with was one of the > >44x44 heroes from 'fantasy.imf'. Shouldn't the other images have been > >aligned precisely over it, since it is terrain-sized? > > Not necessarily. The background (terrain) is drawn using 32x32 tiles that > fit snugly together, just as if the background was a map. Well, not quite. I thought you said earlier that Xconq hexes were 44x48. (I may be mistaken, though, and it might have been in our private thread.) If they were 32x32, then the entire hex would be covered by a 32x32 image; if the unit had occupants, then the hex would be entirely obscured (as well as part of the surrounding hexes). >You will notice > that if a 44x48 image is used as a tile, it is trimmed to 32x32 size first. But why? If that's not the same size as the cell actually used with 32x32 views in Xconq, then what is the point? And I think you must mean "scaled" instead of "trimmed", because the bright "transparent" border colors outlining the hex were still showing. If cropping had taken place, then most, if not all, of that would have gone away. I will double-check to make sure that this is what I saw, but I am fairly certain. > Now, individual unit images in IMFApp are positioned in a way that bears no > relationship to the background tiles. >The program just checks how wide the > window is, and then computes how many columns it can squeeze in. Therefore, > if you resize the window by a small amount (not enough to change the number > of columns) you will find that the unit images move, while the background > tiles stay the same. OK. This is really non-intuitive to me. I don't see any useful purpose to tiling a background with hexes, if units don't sit in the middle of the hexes, so that one can actually see how they look in a given terrain. Instead of tiling the background with off-scale images of the given terrain image, why doesn't IMFApp just place regular Xconq-sized hexes under each unit on the display grid (forget about tiling ad nauseum), so that each unit can appear as a "cameo" in a distinct hex cell? Eric