Map drawing glitch in latest CVS snapshot

Map drawing glitch in latest CVS snapshot

[Skeezics Boondoggle]

Hi, all.  I'm newly subscribed to the list, but have been lurking about
reading the archives and playing xconq for a couple of years now.

Last week I snagged another CVS snapshot and built it (my previous build
was in Sept. '02).  Everything built smoothly, but the game now has a
weird drawing glitch when moving units - they leave behind a black and
white diagonally hatched pattern in a portion of the adjoining cells as
they move.  Refreshing the screen clears them right up, but the effect
makes it pretty hard to play.

The environment is Solaris 7 (HW11/99 + patches through last month),
Tcl/Tk 8.3.4.  Built with the Sun compiler, if that matters.  I'm running
OpenWindows & olvwm (yeah, I know :-) and get the same glitches on an
Ultra2/Creator and a Sparc 20/SX.  I built the sources from a CVS checkout
the afternoon of June 28th.

Anyone else run into this?  I could probably put up a screenshot somewhere
if that would help.  It's a pretty obvious glitch, so I'm wondering if
there just aren't that many Solaris/Openwin xconq players left out there?  
:-)

Cheers,

-- Chris

Re: Map drawing glitch in latest CVS snapshot

[Hans Ronne]

>Hi, all.  I'm newly subscribed to the list, but have been lurking about
>reading the archives and playing xconq for a couple of years now.
>
>Last week I snagged another CVS snapshot and built it (my previous build
>was in Sept. '02).  Everything built smoothly, but the game now has a
>weird drawing glitch when moving units - they leave behind a black and
>white diagonally hatched pattern in a portion of the adjoining cells as
>they move.  Refreshing the screen clears them right up, but the effect
>makes it pretty hard to play.
>
>The environment is Solaris 7 (HW11/99 + patches through last month),
>Tcl/Tk 8.3.4.  Built with the Sun compiler, if that matters.  I'm running
>OpenWindows & olvwm (yeah, I know :-) and get the same glitches on an
>Ultra2/Creator and a Sparc 20/SX.  I built the sources from a CVS checkout
>the afternoon of June 28th.
>
>Anyone else run into this?  I could probably put up a screenshot somewhere
>if that would help.  It's a pretty obvious glitch, so I'm wondering if
>there just aren't that many Solaris/Openwin xconq players left out there?

It's certainly not something I have ever seen under Linux. But we should
try to fix it anyhow. It would help a lot if you could check out a couple
of time snapshots and narrow down exactly when this bug first appeared.

Hans

Re: Map drawing glitch in latest CVS snapshot

[Skeezics Boondoggle]

On Tue, 1 Jul 2003, Hans Ronne wrote:
> 
> It's certainly not something I have ever seen under Linux. But we should
> try to fix it anyhow. It would help a lot if you could check out a couple
> of time snapshots and narrow down exactly when this bug first appeared.

I unpacked the source RPM [0] I had of the previous version that was
working without this glitch; it was checked out in September '02.  I
thought it was more recent than that...

Anyway, in doing some recursive diffs against the x11 and tcltk
subdirectories, I quickly realized that it's going to take some time to
wrap my head around this code.  There's a lot in there, and quite a few
diffs in the last nine months. :-)  

I started up a game to take a few screenshots.  I bet that someone
familiar with the code could probably jump right to the spot where things
are wonky with a visual of the effect I'm talking about... But just a
couple of turns into the game I got a couple of pop-ups that said:

Should not be calling xmalloc (requested 34 bytes)
Should not be calling xmalloc (requested 36 bytes)

after which the game crashed.  Twice.  Hmmm.  I've never seen that message
before... I'm thinkin' it's time to turn on debugging and rebuild.  I'll
have to try again tomorrow to get a screen shot.

In any case, I paid closer attention to the behavior of it:  the glitch
appears in the hexes surrounding the moving unit, but not in its wake.  
Any hex partially obscured by the glitch is quickly redrawn if there's an
attack, if the window is recentered, or when the turn ends.  Often, if the
unit is just moving one cell (an infantry with nothing around) there's no
visual artifacts at all; things look normal.  When moving a fighter or
bomber, however, things get pretty crazy.  Lots of xor's goin' on. :-)

Now that I think of it, I'm wondering if this is related to another couple
of minor things:  when zooming in on the map, the grid lines are big and
fat until you refresh the window... and sometimes (often quite a few turns
into a game) there's a lag between clicking on a unit or town in survey
mode and the stats for that unit being displayed - that is, if I click on
a unit that's partially built I'll still see the stats for the last thing
I clicked on; if I click on the town, then, the stats for the unit I
wanted to investigate then show up... could all of these things be subtly
related?  It's as if in each case there's a call missing to flush the last
bit of output and update the display.  (Ugh, sorry this is all so
imprecise, I've only just started poking around in the code.  I've been a
sysadmin for too many years, not a coder - the old brain cells are rusty.
:-)

The only options I generally play with are "world seen", grid on, coverage
on, and nothing else (no unit/feature names, meridians, etc).  So far in
this version I've only tried out the standard and advanced games, but I'm
guessing it's the same in other scenarios too.  

-- Chris

[0] Yeah, I run OpenWin and olvwm, AND I build all my Solaris add-on
packages with RedHat Package Manager.  Other than that I'm almost
completely sane, really.

Re: Map drawing glitch in latest CVS snapshot

[Hans Ronne]

>On Tue, 1 Jul 2003, Hans Ronne wrote:
>>
>> It's certainly not something I have ever seen under Linux. But we should
>> try to fix it anyhow. It would help a lot if you could check out a couple
>> of time snapshots and narrow down exactly when this bug first appeared.
>
>I unpacked the source RPM [0] I had of the previous version that was
>working without this glitch; it was checked out in September '02.  I
>thought it was more recent than that...
>
>Anyway, in doing some recursive diffs against the x11 and tcltk
>subdirectories, I quickly realized that it's going to take some time to
>wrap my head around this code.  There's a lot in there, and quite a few
>diffs in the last nine months. :-)

There is a much easier way. Use cvs -D date. Start with a date midway
between September 02 and now. Build xconq and check if the bug is there.
Then pick a second date between that date and one of the first two. And so
on. Typically, a handful of checkouts (less than one hour of work) can
pinpoint exactly when the bug first appeared.

This is something only you (or somebody else with Solaris) can do. Without
this information, there is little I can do. I made a large number of
changes in the tcltk interface in the last few months, and it is impossible
for me to tell which one of them causes problems under Solaris.

Hans

Re: Map drawing glitch in latest CVS snapshot

[Eric McDonald]

On Wed, 2 Jul 2003, Hans Ronne wrote:

> >On Tue, 1 Jul 2003, Hans Ronne wrote:
> >>
> There is a much easier way. Use cvs -D date. Start with a date midway
> between September 02 and now. Build xconq and check if the bug is there.
> Then pick a second date between that date and one of the first two. And so
> on. Typically, a handful of checkouts (less than one hour of work) can
> pinpoint exactly when the bug first appeared.

IOW, a binary search.

Re: Map drawing glitch in latest CVS snapshot

[Skeezics Boondoggle]

On Wed, 2 Jul 2003, Hans Ronne wrote:

> There is a much easier way. Use cvs -D date. Start with a date midway
> between September 02 and now. Build xconq and check if the bug is there.
> Then pick a second date between that date and one of the first two. And so
> on. Typically, a handful of checkouts (less than one hour of work) can
> pinpoint exactly when the bug first appeared.

Yeah, that makes sense.  I was hoping to maybe understand the code and 
just produce a patch :-) but if I can at least help pinpoint when things 
changed/broke, maybe that'll help.

> This is something only you (or somebody else with Solaris) can do. Without
> this information, there is little I can do. I made a large number of
> changes in the tcltk interface in the last few months, and it is impossible
> for me to tell which one of them causes problems under Solaris.

The updates are much appreciated - especially in the networking code.  On
those rare occasions when I can pull my son away from his whizzy 3D
multi-player shoot'em'ups to go a few rounds on the old Sparcstation (or
now with Apple's X11 available for MacOSX) it's fun to torture him with a
game that requires a little more thought, strategy and patience than the
typical twitchy FPS games so prevalent today.  He can whoop me at Quake3
but can't even come close at MazeWar... go figure. :-)  And xconq proves 
that "old age and treachery overcomes youth and skill."  Heh heh.

I'll post more info when I've had time to do some more test builds.

Cheers,

-- Chris