Improved IMFApp

Improved IMFApp

[Hans Ronne]

I have checked in the improved IMFApp that I have been working on recently.
It no longer needs 1 GB of memory and 45 minutes to load imf.dir (well,
things were not quite that bad, but almost).

A large number of other problems have been fixed as well, which are listed
in the ChangeLog.

If you wonder what IMFApp is, it's the small image editor that comes with
Xconq. In retrospect, I ask myself why I put a lot of work into improving
an application that I guess only a handful of people ever use. But here it
is, nonetheless ...

Hans

Re: Improved IMFApp

[Eric McDonald]

Hans Ronne wrote:

> I have checked in the improved IMFApp that I have been working on recently.
> It no longer needs 1 GB of memory and 45 minutes to load imf.dir (well,
> things were not quite that bad, but almost).

It loaded fairly quickly on my Linux box. Inside a virtual machine on my 
hardware takes a little over a minute, which is probably quite fast, 
given how long a Xconq compile takes in the VM.

The image-loading progress report is a nice touch.

I think the top-level window size is too big. In the ChangeLog, I think 
you said you changed it to 900x600 (which is much bigger than 640x480, 
and would be unwieldy at 800x600). Even at the 1024x768 resolution I 
prefer (my best monitor is 8 years old, and does not have a particularly 
good dot pitch, so higher resolutions are too hard to read text in), the 
window seems too big.

> In retrospect, I ask myself why I put a lot of work into improving
> an application that I guess only a handful of people ever use. 

Well, that handful (game developers) is a very important handful. And, I 
think your work is appreciated by that handful.

Eric

Re: Improved IMFApp

[Hans Ronne]

>The image-loading progress report is a nice touch.

Thanks. It is interesting to see what images are causing problems, and on
what platforms. The terrain images (which usually contain a number of
subimages of different sizes) obviously take a long time to load. More
surprisingly, the pg images take a humongous time to load, but only under
Windows. I wonder why. They are just gifs, like the other images. And it's
not just that there are a lot of them to load - every single pg image takes
a very long time.

>I think the top-level window size is too big. In the ChangeLog, I think
>you said you changed it to 900x600 (which is much bigger than 640x480,
>and would be unwieldy at 800x600). Even at the 1024x768 resolution I
>prefer (my best monitor is 8 years old, and does not have a particularly
>good dot pitch, so higher resolutions are too hard to read text in), the
>window seems too big.

Both window size and position should ideally be scaled to the screen, but
this part of tcl is buggy. Caused a lot of problems in Xconq, too. I'll see
if I can get it to work properly.

>If the background color is changed to to black, the black text used for
>image names no longer shows up (not surprising), and setting the
>foreground color does not appear to remedy the situation
>(semi-surprising). Perhaps text color needs to be tied to foreground
>color, or else a separate text color submenu created.

Yes. There is definitely room for improvements also in the menu layout.
What is called "foreground color" is actually the background color of the
closeups and in the grid mode. And some menu options (" as unit" etc) do
nothing. I'm not even sure what Stan intended to do with these. The
corresponding tcl procedures were just empty shells.

>Slightly more ambitious idea: always set the image name text color to
>the diametrically opposite color of the background color.

This is how the selection box works in the MacOS native IMFApp. However, it
doesn't look too good, so I kept it black in the tcltk version. It is
therefore also invisible against black. We probably should set both text
and box to white in that case.

Hans

P.S. The "Selected as Terrain" option does nothing under Windows, but this
is because tiled drawing doesn't work at all on that platform.

Re: Improved IMFApp

[Eric McDonald]

On Wed, 4 Aug 2004, Hans Ronne wrote:

> subimages of different sizes) obviously take a long time to load. More
> surprisingly, the pg images take a humongous time to load, but only under
> Windows. 
>I wonder why. 

Yes, I noticed this and also wondered about it.
I don't have any thoughts on why it might this way, unless the 
GIF-to-pixel-array routine is platform-dependent for some odd 
reason.

> Yes. There is definitely room for improvements also in the menu layout.
> What is called "foreground color" is actually the background color of the
> closeups and in the grid mode. 

I noticed that.

>And some menu options (" as unit" etc) do
> nothing. I'm not even sure what Stan intended to do with these. The
> corresponding tcl procedures were just empty shells.

Maybe we can cast a "Summon Stan" and find out. The thread length 
is probably not quite long enough to attract his interest yet, but 
after a few more replies it might be. :-)

> P.S. The "Selected as Terrain" option does nothing under Windows, but this
> is because tiled drawing doesn't work at all on that platform.

Right. I haven't forgotten that I was looking into that. I just 
got distracted with other things more recently.

Eric

Re: Improved IMFApp

[Hans Ronne]

I have now checked in the improvements we just discussed. I also made the
"Save Selected Only" menu option work. This makes it possible to save
individual imfs, which is useful for moving imfs between files.

Hans

Re: Improved IMFApp

[Eric McDonald]

Hans Ronne wrote:

> I have now checked in the improvements we just discussed. 

Looks good.

>I also made the
> "Save Selected Only" menu option work. This makes it possible to save
> individual imfs, which is useful for moving imfs between files.

Handy indeed. The lack of this capability was one of the things that I 
thought previously limited the usefulness of the program.

Eric

Re: Improved IMFApp

[Jim Kingdon]

> Maybe we can cast a "Summon Stan" and find out. The thread length 
> is probably not quite long enough to attract his interest yet, but 
> after a few more replies it might be. :-)

Don't we need to suggest rewriting IMFApp in GTK for that?

Maybe with a little animated paper clip to help people who are having
trouble using it.

IMFApp Office (was Re: Improved IMFApp)

[Eric McDonald]

On Thu, 5 Aug 2004, Jim Kingdon wrote:

> > Maybe we can cast a "Summon Stan" and find out. The thread length 
> > is probably not quite long enough to attract his interest yet, but 
> > after a few more replies it might be. :-)
> 
> Don't we need to suggest rewriting IMFApp in GTK for that?

Yes, and make sure that it has lots of modeless windows all being 
used at the same time. A built-in spreadsheet window would also be 
nice.

> Maybe with a little animated paper clip to help people who are having
> trouble using it.

;-)

Re: IMFApp Office

[Hans Ronne]

I have checked in more IMFApp fixes. I also fixed a bunch of menu problems
in xconq itself. The AI type and desinger menu items were not updating
correctly, and the on/off checkmarks were not working at all under Windows.
It's amazing how new bugs still keep popping up that we didn't notice
before.

I have also checked in Henry Cobb's improvements to the Time game.

Hans

Re: IMFApp Office

[Eric McDonald]

Hans Ronne wrote:

> It's amazing how new bugs still keep popping up that we didn't notice
> before.

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?

> I have also checked in Henry Cobb's improvements to the Time game.

Good.

Eric

Re: IMFApp Office

[Hans Ronne]

>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.

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.

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.

To handle these bigger 44x48 images, I hacked the interface code, and added
a global flag big_unit_images, which is set to true if any image in the
game has a width of more than 32 pixels.

Now, what you have in wreckreation.gif are two images with completely
non-standard sizes: 38x64 and 30x64. There is no support for this in the
current interface code. The first image is wider than 32 pixels, and would
therefore be interpreted as a 44x48 images and set the big_unit_images
flag. the second image would be interpreted as a 32x32 image.

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. In practice, this happens only to the
wider of the two images in the tcltk interface, but to both of them in the
Mac interface.

In IMFApp, the initial drawing just uses the real size of the images
without any scaling. After an image has been selected, however, all image
sizes have been inited, and the code then uses the "best" of them. You may
have noticed that some B/W emblems are initially drawn at their correct
(small) size but at twice that size after being cliked on.  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.

My advice would be to try to keep images within the bounds Xconq expect,
i.e. either 32x32 or 44x48. I always scale images to that size when I make
gifs. In addititon, it is a good idea to keep the 44x48 images within a
hexagon. I use this magenta/green background grid that you may have noticed
in my gifs to ensure that this is the case.

Hans

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. The
same thing also happens with Elijah's "cil" game. This is because of a
hidden but fully functional feature that I added last year (ported from the
mac interface), which makes it possible to have preview images for each
game. Right now, all of them load the same image, which is the old popup
screen. However if you give a gif the same name as a game, that gif is
loaded instead. I have prepared gifs for a number of the games but have not
had time to finish the job yet.

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).

P.P.S. Preview gifs should be exactly 240 x 160 pixels. That is why your
iamge is distorted.

Re: IMFApp Office

[Eric McDonald]

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

Re: IMFApp Office

[Hans Ronne]

>> 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).

Strange. I don't see any black patches under either Mac OS or Linux/X11.
The only thing I see is the failure to scale the images correctly on the
first attempt.

>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.

That's a nice idea. Images at 64x64 are generally so ugly that I never use
that magnification. And it seems that scaling of your images works, after
some initial confusion, both at 32x32 and 64x64.

>> 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?

That's also what it does, at least under Mac TCL.

>> 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.

Well, let me modify that. On the Mac, the image gets distorted (i.e.
expanded to 240 x 160 pixels). In the tcltk interface, however, a smaller
image is drawn instead.

Hans

Re: IMFApp Office

[Eric McDonald]

Hans Ronne wrote:

> Strange. I don't see any black patches under either Mac OS or Linux/X11.
> The only thing I see is the failure to scale the images correctly on the
> first attempt.

I am defnitely significant patchy black regions surrounding the images 
when they are initially drawn with incorrect scaling in the 32x32 
bounding boxes on the display grid.

>>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. 
> 
> That's a nice idea. 

Thanks.

>Images at 64x64 are generally so ugly that I never use
> that magnification. 

Well, my idea is to have Wreckreation actually look decent at that 
magnification. Last time, I was at that view power (probably about half 
a year ago), I thought I saw connector drawing problems (maybe with the 
Standard game). I will have to recheck that.

>And it seems that scaling of your images works, after
> some initial confusion, both at 32x32 and 64x64.

I wish there was a 44x44 view in IMFApp for the special big images. I 
tried doing view "Selected as Terrain", but all that did was make a hex 
pattern with the image inside each hex on the display grid. It did 
nothing to the closeup views. Also, the other images in the IMF file 
were still superimposed on top of the display grid, even though it was 
now a hex pattern instead of invisible rectangles.

Eric

Re: IMFApp Office

[Hans Ronne]

>Hans Ronne wrote:
>
>> Strange. I don't see any black patches under either Mac OS or Linux/X11.
>> The only thing I see is the failure to scale the images correctly on the
>> first attempt.
>
>I am defnitely significant patchy black regions surrounding the images
>when they are initially drawn with incorrect scaling in the 32x32
>bounding boxes on the display grid.

This must be a hardware-related issue since I don't see it. Does it also
happen under Windows on the same machine? And do you see it with other
images as well, or just with the non-standard size wreckreation images?

>I wish there was a 44x44 view in IMFApp for the special big images.

In fact, the 32x32 view is really 44x48, to accomodate the special big
images. And the 16x16 view is really 24x26. And so on.

>I tried doing view "Selected as Terrain", but all that did was make a hex
>pattern with the image inside each hex on the display grid. It did
>nothing to the closeup views. Also, the other images in the IMF file
>were still superimposed on top of the display grid, even though it was
>now a hex pattern instead of invisible rectangles.

Well, that is how the Selected as Terrain is supposed to work, i.e. to draw
all units agains the selected image as background. The closeups are not
supposed to be affected. Naturally, it will look strange if you select a
unit image as terrain, but the program does it anyway.

Hans

Re: IMFApp Office

[Eric McDonald]

Hans Ronne wrote:

>>Hans Ronne wrote:
> This must be a hardware-related issue since I don't see it. Does it also
> happen under Windows on the same machine? And do you see it with other
> images as well, or just with the non-standard size wreckreation images?

I have not seen this with any other images.
Testing under Windows would not be of much help on my machine, since 
that OS runs on virtual hardware. Windows XP video is done on a VMware 
virtual SVGA adapter (and is then presumably sent as a pixmap or 
something to be put up in a X display), whereas my Linux video is on a 
GeForce card which is only about 2.5 years old. If this was a hardware 
issue, I think I would be noticing problems elsewhere....

> In fact, the 32x32 view is really 44x48, to accomodate the special big
> images. And the 16x16 view is really 24x26. And so on.

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...?

> Well, that is how the Selected as Terrain is supposed to work, i.e. to draw
> all units agains the selected image as background. The closeups are not
> supposed to be affected. Naturally, it will look strange if you select a
> unit image as terrain, but the program does it anyway.

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?

Eric

Re: IMFApp Office

[Hans Ronne]

>> In fact, the 32x32 view is really 44x48, to accomodate the special big
>> images. And the 16x16 view is really 24x26. And so on.
>
>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.

>> Well, that is how the Selected as Terrain is supposed to work, i.e. to draw
>> all units agains the selected image as background. The closeups are not
>> supposed to be affected. Naturally, it will look strange if you select a
>> unit image as terrain, but the program does it anyway.
>
>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. You will notice
that if a 44x48 image is used as a tile, it is trimmed to 32x32 size first.

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.

Hans

Re: IMFApp Office

[Eric McDonald]

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

Re: IMFApp Office

[Hans Ronne]

>>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.

No, the images are indeed cropped, not scaled. For example, you will notice
that the top and the bottom corners of the background hexes have been
trimmed off.

There are actually two completely different ways to draw terrain in Xconq:
as tiles or as individual images.

Tiled drawing always uses square images that are not necessarily lined up
with the hex grid. These square images are found either in special gif
files (sea.gif and advt32x32.gif) or in terrain.imf itself (everything
named "tile", e.g. (imf "plains" ((64 64 tile) ...

Non-tiled terrain drawing uses the 44x48 sized hexagons that you find in
files like advt44x48.gif. In this case, each individual cell is drawn
separately. The files usually contain a row of subimages that are used in a
semi-random way to provide some variety. If a non-tiled image is encoded
directly in an .imf file, it is called a "terrain" image instead of a
"tile" image.

Now, if IMFApp does not find a special "tile" image (which it will never do
in the case of a unit) it will make one from the available image and use it
as a tile. That is why the background unit images are trimmed to 32x32
size. They were converted to "tiles" before being used to draw the
background.

I would add that the whole tile drawing machinery is semi-obsolete, a
remnant from the time when Xconq did not have true images. The best way to
draw terrain is certainly the latter, on any platform that supports it
(meaning everything but cconq and xtconq). Tiled drawing is now mainly used
a small magnifications, usually in the world map, where there are no
hexagon images available (and where cells are square-shaped anyway).

One could of course make IMFApp draw backgrounds by using individual images
instead of tiles, but this would require a lot of work, so I did not assign
it a high priority.

Hans

Re: IMFApp Office

[Eric McDonald]

Hans Ronne wrote:

> There are actually two completely different ways to draw terrain in Xconq:
> as tiles or as individual images.

I had gathered that from browsing the IMF's a few days ago, and also 
previously from noticing that some terrains were drawn as squares (as 
with colors) in IMFapp, but others, like the Civ2 terrains, were drawn 
in hexagons.

> Now, if IMFApp does not find a special "tile" image (which it will never do
> in the case of a unit) it will make one from the available image and use it
> as a tile. That is why the background unit images are trimmed to 32x32
> size. They were converted to "tiles" before being used to draw the
> background.

OK. That is fine for a technical explanation of what is happening, but 
it still not very intuitive from an user's persepctive, I think.

> I would add that the whole tile drawing machinery is semi-obsolete, a
> remnant from the time when Xconq did not have true images. The best way to
> draw terrain is certainly the latter, 

I would agree; it seems that that would be less computationally expensive.

> One could of course make IMFApp draw backgrounds by using individual images
> instead of tiles, 

This is more like what I had expected.

Eric

Re: IMFApp Office

[Eric McDonald]

There appears to be a bug with IMFApp when it is attempting to draw a 
closeup of an IMF which has multiple definitions.

When viewing the Cast Iron Life images, the 8x8 closeup (which is 
defined separately, but has the same name as the larger image definition 
in the IMF file) appears oddly, and the correct image is not displayed.

Eric

Re: IMFApp Office

[Eric McDonald]

Eric McDonald wrote:

> When viewing the Cast Iron Life images, the 8x8 closeup (which is 

I meant the so-called "16x16" closeup, not the 8x8 one.

Re: IMFApp Office

[Hans Ronne]

>There appears to be a bug with IMFApp when it is attempting to draw a
>closeup of an IMF which has multiple definitions.
>
>When viewing the Cast Iron Life images, the 8x8 closeup (which is
>defined separately, but has the same name as the larger image definition
>in the IMF file) appears oddly, and the correct image is not displayed.

I noticed this. I would say that what really happens is that those units
(not all of them) that have an 8x8 image for some reason is using it at
16x16 magnification, too, instead of scaling down the 32x32 image. I don't
think IMFApp is to blame for this, but rather the general image scaling
code (best_image) which is used by both Xconq and IMFApp. It is unusal to
provide 32x32 and 8x8 images, but not 16x16, so the code may get confused.

Hans

Re: IMFApp Office

[Eric McDonald]

On Wed, 11 Aug 2004, Hans Ronne wrote:

> I noticed this. I would say that what really happens is that those units
> (not all of them) that have an 8x8 image for some reason is using it at
> 16x16 magnification, too, instead of scaling down the 32x32 image. 

Really? At least in my closeups, it appeared that the top left 
corner of the 44x44 was appearing unscaled, and with the 
transparency colors unsuppressed) in the "16x16" (22x24?) view 
box.

>I don't
> think IMFApp is to blame for this, but rather the general image scaling
> code (best_image) which is used by both Xconq and IMFApp. It is unusal to
> provide 32x32 and 8x8 images, but not 16x16, so the code may get confused.

Then this is even more bothersome to me, because I would like to 
provide an actual family of images which have distinct images (but 
same name) for each view size, and if the code that handles this 
is used in Xconq, then things could get ugly.

Eric

Re: IMFApp Office

[Hans Ronne]

>On Wed, 11 Aug 2004, Hans Ronne wrote:
>
>> I noticed this. I would say that what really happens is that those units
>> (not all of them) that have an 8x8 image for some reason is using it at
>> 16x16 magnification, too, instead of scaling down the 32x32 image.
>
>Really? At least in my closeups, it appeared that the top left
>corner of the 44x44 was appearing unscaled, and with the
>transparency colors unsuppressed) in the "16x16" (22x24?) view
>box.

This is an aspect of another problem (failure to scale some images
correctly on the first attempt) that we already discussed for the emblems.
After you click on the image, however, it will be scaled correctly from
32x32 to 16x16. But the 8x8 images override the scaled image at this point,
which they should not do (at least not at 16x16 resolution).

>>I don't
>> think IMFApp is to blame for this, but rather the general image scaling
>> code (best_image) which is used by both Xconq and IMFApp. It is unusal to
>> provide 32x32 and 8x8 images, but not 16x16, so the code may get confused.
>
>Then this is even more bothersome to me, because I would like to
>provide an actual family of images which have distinct images (but
>same name) for each view size, and if the code that handles this
>is used in Xconq, then things could get ugly.

If you provide an entire family you should be safe. It is only if you leave
a hole in the middle that the code apparently gets confused. The fix is
probably trivial, like changing a < to a <=, but I haven't had time to look
into this since I assigned the path-finding bug a higher priority.

Hans

Re: Improved IMFApp

[Eric McDonald]

Hans Ronne wrote:

> I have checked in the improved IMFApp that I have been working on recently.

If the background color is changed to to black, the black text used for 
image names no longer shows up (not surprising), and setting the 
foreground color does not appear to remedy the situation 
(semi-surprising). Perahps text color needs to be tied to foreground 
color, or else a separate text color submenu created.

Slightly more ambitious idea: always set the image name text color to 
the diametrically opposite color of the background color.

Eric