Re: IMFApp Office

[Eric McDonald <mcdonald@phy.cmich.edu>]

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