Re: Improved scaler

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

mskala@ansuz.sooke.bc.ca wrote:

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

I'll look into these.

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

Right. I think we can live with this for now. Perhaps some games can be 
made to use different terrain tile sets (where appropriate). The 
existing tile sets might also be able to built for other resolutions by 
taking a copy of them, rescaling them to the new resolution, then 
acquiring brushes based on the patterns in the tiles at the original 
scaling, and using those brushes to paint in the better-looking patterns 
at the new scaling.

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

[snipped]

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

Hmmm.... Could the 'terrain' keyword, which is used in the .imf for the 
advterr tiles, IIRC, be taken as a hint to fill in the jaggies 
automatically?

> Index: kernel/imf.c
> ===================================================================
> RCS file: /cvsroot/xconq/xconq/kernel/imf.c,v
> retrieving revision 1.2
> diff -c -r1.2 imf.c
> *** kernel/imf.c	25 Nov 2004 06:59:29 -0000	1.2
> --- kernel/imf.c	30 Nov 2004 05:28:07 -0000
> ***************
> --- 32,47 ----
>       K_OTHER_
>   };
>   
> + typedef struct _MFEntry {
> +     int value, count;
> + } MFEntry;
> + typedef MFEntry *ModeFilter;
> + 

This patch seems good to me. The only thing that we might wish to change 
is "_MFEntry" to "a_mf_entry". Xconq seems to use this convention for 
such struct definitions, and I think that using a leading underscore 
could get us into trouble (not in this particular case) with the 
internals of some libraries. For example, the GNU standard C/C++ and 
system headers seem to often use this convention either for internal 
work or providing an alternative definition when strict ANSI compliance 
is set. Of course, since we now compile Xconq with a C++ compiler, there 
  may not be a need to do the typedef at all.

Other than that, things look fine, insofar as I read them in any detail. 
I will apply and test the patch soon.

   Thanks,
     Eric