This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: IMFApp Office
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: xconq7 at sources dot redhat dot com
- Date: Tue, 10 Aug 2004 15:02:02 -0400 (EDT)
- Subject: Re: IMFApp Office
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