This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
* 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.
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.
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.
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,
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;
+
Thanks, Eric
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |