Attached is a patch (against current mainline CVS) implementing an
improved image scaler.  Since this is done inside imf.c, it should be
applicable to all interfaces.  In my own testing it seems to make XConq a
lot prettier in general, and it fixes the "terrain changes to flat colours
at highest magnification" problem.  It seems to work in both the TCL and
SDL interfaces, which are the only ones I can really test.  However, there
are some issues remaining:

* I'm 99% sure this problem is not caused by my patch because it seems to
exist in the mainline CVS also, but I discovered it while testing this
patch:  some shipped game modules cause the TCL/TK interface to crash with
a segfault.  See attached backtrace.  To replicate the problem, choose the
game "Cave of Wandering Death" in the TCL interface and choose the
defaults for variants and players; the segfault occurs just before the map
window comes up.  I'll probably log it into the SourceForge bug
tracker.  I've seen what seems to be the same bug with a few other game
modules but haven't been able to determine what's special about the ones
that exhibit it.  "Beirut 1982" also segfaults, but it seems like that may
be a different bug because the map window does pop up and messages appear
before it segfaults.

* Subimage scaling is still non-existant (not a new problem, but one that
is not fixed by this patch) so even if you define several alternate
terrain images, only one will be used at any magnifications where the
image must be generated by scaling.

* Some of the existing art doesn't really look very good with the new
scaler's selection rules.  In particular, some image families contain
tiles that clash visually with scaled versions of the non-tile images
from other image families.  To see an example, choose the default game in
the TCL interface with default settings except "world seen" turned on, and
look at the different zoom levels.  At one level, you'll see all the
terrain as tiles, including a nasty-looking brown and white triangle
pattern for mountains, blue with wavy lines for ocean, and yellow and
brown dots for desert.  All the other levels look more photographic, so
it's somewhat jarring to switch between the two.  This is really more an
issue of what's defined in the art than how the scaler works, but having
the scaler always choose the closest match means that the closest match
had better be the image we actually want to use.  A similar issue, though
I haven't actually seen it in practice, would be that if we defined both
colour and monochrome images in the same family, then the scaler might use
them both at different resolutions, to the possible annoyance of the user.

* Similarly: if you take a hexagon at 44x48 and you scale it up to 88x96,
the result will not be a perfect hexagon because the "jaggies" along the
slanted edges will have 2-pixel staircase steps instead of 1-pixel
staircase steps.  If you then attempt to cover a real 88x96 hexagon with
the scaler output, the result will leave some pixels around the edges
uncovered.  To see the effect of this issue, start an "advances" game in
the TCL interface and zoom in to the maximum.  The terrain images are only
defined at 44x48 resolution (maybe also at smaller resolutions) and so
when they're scaled up to 88x96, there are stray pixels along the slanted
edges, resulting in zigzag horizontal grey lines on the display.  I think,
ultimately, that this is an art problem; the art should be defined with
image data a little bigger than the hexagon instead of going up to the hex
edge and then stopping.  That way the scaler will be able to do its job.  
I'm not sure why we bother having masks in cell-terrain images.  The
system doesn't appear to need it; I've successfully used images covering
the entire image rectangle with no mask for cell terrain, and the
interfaces seem to correctly mask out the central hexagon anyway.  
They'll have to, when I get to the advanced terrain image stuff, or else
I'll have to generate hexagonal masks on the fly.

I may be able to edit the GIFs to add some extra pixels of appropriate
colour around the edges of the hexagons.  It seems like this issue affects
very few actual images among the ones we're distributing - the only
example I've found is advt44x48.gif.  I also might be able to tweak the
scaler to fake the extra pixels automatically so that no changes to the
art would be needed, but I'm less happy about that because it would mean
the scaler would have to *know* for sure whether a given image was going
to be used for cell terrain, and I can think of a lot of scenarios where
the automatic fill-in would generate bad data and cause more problems than
it would solve.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/