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]

Re: Map drawing glitch in latest CVS snapshot


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]