emblem drawing glitches on linux

emblem drawing glitches on linux

[Tom Lowshang]

Hi all, my first post to this list.  With so few posters here,
how could anyone _not_ notice a first post? :-)

When moving a unit, I can see emblems being drawn and erased in
adjacent cells if at least one of those cells has not been seen
before.  If another unit becomes active, then the emblems around
first unit remain on the map.  There are other cases where the
emblems remain, but I can't quite figured the pattern out.  I
can erase the extra emblems by redrawing the map, so they are
really just a visual nuisance.  Everything works fine otherwise.

I use xconq under linux (debian sid) and tck/tk 8.4.3.  No
difference with tcl/tk 8.3.5.  I also did a fresh CVS check out,
since I have been messing with the code a bit, but no luck.

Since no one else has reported this problem under linux, I do
wonder whether it is a something peculiar on my system or
perhaps debian, but I am not yet convinced.

Tom

Re: emblem drawing glitches on linux

[Eric McDonald]

On Wed, 25 Jun 2003, Tom Lowshang wrote:

> When moving a unit, I can see emblems being drawn and erased in
> adjacent cells if at least one of those cells has not been seen
> before.  If another unit becomes active, then the emblems around
> first unit remain on the map.  There are other cases where the
> emblems remain, but I can't quite figured the pattern out.  I
> can erase the extra emblems by redrawing the map, so they are
> really just a visual nuisance.  Everything works fine otherwise.

Hi Tom,

  I don't think I have seen your problem on my Linux/X11 system.

  I doubt this is the case, but:
  If you have the People view option turned on, then emblems will be drawn
demarcating your country's border. Furthermore, your emblem will also be placed
on cells in which you have intruded into an enemy's country. Does this perhaps
fit the behavior you are seeing?

  Eric

Re: emblem drawing glitches on linux

[Tom Lowshang]

On Wed, Jun 25, 2003 at 06:28:35PM -0400, Eric McDonald wrote:
> On Wed, 25 Jun 2003, Tom Lowshang wrote:
> 
> > When moving a unit, I can see emblems being drawn and erased
> > in adjacent cells if at least one of those cells has not
> > been seen before.  If another unit becomes active, then the
> > emblems around first unit remain on the map.  There are
> > other cases where the emblems remain, but I can't quite
> > figured the pattern out.  I can erase the extra emblems by
> > redrawing the map, so they are really just a visual
> > nuisance.  Everything works fine otherwise.
> 
> Hi Tom,
> 
>   I don't think I have seen your problem on my Linux/X11
>   system.
> 
>   I doubt this is the case, but: If you have the People view
>   option turned on, then emblems will be drawn demarcating
>   your country's border. Furthermore, your emblem will also be
>   placed on cells in which you have intruded into an enemy's
>   country. Does this perhaps fit the behavior you are seeing?
> 
>   Eric

People view is off but the behaviour is similar in that the
emblems usually never appear in cells your have seen before.
Are you using x11 or tcl/tk interface?

A screenshot would be great right now, but changing focus on the
xconq window redraws the map and clears the errant emblems :-(
so let me try a more detailed description.

I am in the introductory game, turn 4. I move the unit 1 cell
NE, everything is ok. Turn 5, I move NE again, but now 5 emblems
appear briefly in the adjacent cells to the W, NW, NE, E, and SE
of the unit.  The emblems remain long enough to be visible, then
they are erased.  I move NE until turn 8 and the above effect
repeats each turn.  But in turn 8 the next unit is completed, so
now when I move the first unit NE again, the second unit becomes
active, and the 5 emblems remain visible around the first unit.
I move second unit NE.  Turn 9, move second unit NE again, but
no emblems appear in adjacent cells, like they did for first the
unit.  Move first unit NE, the emblems quickly appear and
disappear again.  Turn 10, unit 1 is still active so I move it
NE.  When the second unit becomes active, the 5 emblems around
the first unit are again left on the map.

Phew, that's enough I hope.  Note that was the simplest possible
example could come up with.  I played a complete introductory
game and I could tell there were more complicated patterns
occurring, so I hope the simple case is helpful.

Tom

Re: emblem drawing glitches on linux

[Eric McDonald]

On Wed, 25 Jun 2003, Tom Lowshang wrote:

> People view is off but the behaviour is similar in that the
> emblems usually never appear in cells your have seen before.
> Are you using x11 or tcl/tk interface?

I am using the Tcl/Tk interface on X11. Are you using the Xt/Xaw interface?

> A screenshot would be great right now, but changing focus on the
> xconq window redraws the map and clears the errant emblems :-(

IIRC, xv had a time-delayed screen capture option (so a user could get shots of
selected menu items, etc...). That would give you time to move a unit and then
tell the wayward emblems to say cheese.


Eric

Re: emblem drawing glitches on linux

[Tom Lowshang]

On Thu, Jun 26, 2003 at 01:19:53AM -0400, Eric McDonald wrote:
> On Wed, 25 Jun 2003, Tom Lowshang wrote:
> 
> > Are you using x11 or tcl/tk interface?
> 
> I am using the Tcl/Tk interface on X11. Are you using the
> Xt/Xaw interface?

No, I am using tcl/tk interface, with tcl/tk 8.4.3.  Which
version of tcl/tk are you using?  However, I don't think the
problem relates to tcl/tk version since I tried 8.3.5 and the
same thing occured.

> 
> > A screenshot would be great right now, but changing focus on
> > the xconq window redraws the map and clears the errant
> > emblems :-(
> 
> IIRC, xv had a time-delayed screen capture option

Good idea! I will check into this.

Tom

Re: emblem drawing glitches on linux

[Eric McDonald]

On Thu, 26 Jun 2003, Tom Lowshang wrote:

> No, I am using tcl/tk interface, with tcl/tk 8.4.3.  Which
> version of tcl/tk are you using?  However, I don't think the
> problem relates to tcl/tk version since I tried 8.3.5 and the
> same thing occured.

I am using Tcl/Tk 8.3.3. I agree that the Tcl version is probably not the issue.

On a somewhat unrelated note, could you tell me if you get BadWindow and
BadDrawable messages on your console from games that are started from the setup
dialogs (as opposed to starting them with -g from the command line)? Of
some interest is whether these are occuring with Tk 8.4 and higher....

  Thanks,
	Eric

(linux) xconq errors at exit

[Tom Lowshang]

On Thu, Jun 26, 2003 at 05:49:23PM -0400, Eric McDonald wrote:
> 
> On a somewhat unrelated note, could you tell me if you get
> BadWindow and BadDrawable messages on your console from games
> that are started from the setup dialogs (as opposed to
> starting them with -g from the command line)? Of some interest
> is whether these are occuring with Tk 8.4 and higher....
> 

If I start xconq on console, I get "X error on display :0.0:
BadWindow (invalid Window parameter)" when xconq exits only. The
message repeat several time.  This happens whether I use -g or
setup dialogs.

I also just discovered that that xconq does not handle the
window closing well, either.  If I close a setup dialog, xconq
does not exit until I interrupt it with control-c.  If I close
the map window, I see the above message, followed by:

Fatal error encountered. Signal 11

Error: invalid command name ".m1.leftside.topside.notices.t"
Error: while evaluating `low_notify {Game was saved to
"/home/tlow/.xconq/ERRsave.xcq".
}'
Aborted

I usually do not run xconq from a console, so I have not seen
these messages before.

Tom

Re: (linux) xconq errors at exit

[Hans Ronne]

>On Thu, Jun 26, 2003 at 05:49:23PM -0400, Eric McDonald wrote:
>>
>> On a somewhat unrelated note, could you tell me if you get
>> BadWindow and BadDrawable messages on your console from games
>> that are started from the setup dialogs (as opposed to
>> starting them with -g from the command line)? Of some interest
>> is whether these are occuring with Tk 8.4 and higher....
>>
>
>If I start xconq on console, I get "X error on display :0.0:
>BadWindow (invalid Window parameter)" when xconq exits only. The
>message repeat several time.  This happens whether I use -g or
>setup dialogs.

The BadWindow/BadDrawable message is triggered by using the "wm withdraw"
command within the tcl script, and this always happens at the end of the
setup dialog (when the dialog is withdrawn). If you look at the error
messages you will find that there is one pair less if you use -g since one
tcl window less (the setup dialog) is withdrawn in that case. This is what
Eric meant. The other error messages come from other dialogs that you close
during the game or during exit.

>I also just discovered that that xconq does not handle the
>window closing well, either.  If I close a setup dialog, xconq
>does not exit until I interrupt it with control-c.  If I close
>the map window, I see the above message, followed by:
>
>Fatal error encountered. Signal 11

This is a known problem. I don't think it's related to the BadDrawable
messages.

Hans

Re: (linux) xconq errors at exit

[Eric McDonald]

On Thu, 26 Jun 2003, Tom Lowshang wrote:

> If I start xconq on console, I get "X error on display :0.0:
> BadWindow (invalid Window parameter)" when xconq exits only. The
> message repeat several time.  This happens whether I use -g or
> setup dialogs.

Which Tk is this with? (Not that it probably matters; I am simply looking for
data points...)

Also, when you say "when xconq exits only", do you mean you watch these
messages only appear on your console while Xconq is exiting and not before?
And, if so, were any other Xconq windows, besides the one that contains the map
displays, open?

> Fatal error encountered. Signal 11

That's a segmentation fault. There is deeply entwined interaction between the
Tcl/Tk part of the interface and the C part of the interface, and if something
goes away in one (and its memory gets deallocated) then the other might very
well get a little bit upset. Probably more safeguards could be put in place....
It's something I might investigate once I find a way to appropriately deal with
the BadWindow/BadDrawable stuff.

  Thanks for the data,
	Eric

Re: (linux) xconq errors at exit

[Tom Lowshang]

On Thu, Jun 26, 2003 at 09:02:51PM -0400, Eric McDonald wrote:
> 
> Which Tk is this with? (Not that it probably matters; I am
> simply looking for data points...)

8.4.3

> 
> Also, when you say "when xconq exits only", do you mean you
> watch these messages only appear on your console while Xconq
> is exiting and not before?  And, if so, were any other Xconq
> windows, besides the one that contains the map displays, open?

Yes, that is what I meant, but I was bit hasty in that
conclusion.  After pressing Q, the messages actually appear
whenever one of the exit dialogs opens and/or closes.  The
specific exit dialogs that I am refering to are "Do you want to
save game before quitting", "You cannot quit without resigning",
and "You lost!". 

Hope this helps.

Tom

[RFC] Possible BadWindow/BadDrawable Fix

[Eric McDonald]

  So far the only way I have been able to get rid of the BadWindow errors in
the Tcl/Tk interface on X is to destroy a window after it is withdrawn.

This can be done in tkconq.tcl with:

  wm withdraw .windowpath
  destroy .windowpath

Perhaps the "destroy" part could be wrapped in:

  if { "$tcl_platform(platform)" == "unix" } { }

Or it can be done in tkmain.c with:

  tkwin = Tk_NameToWindow(interp, ".windowpath", Tk_MainWindow(interp));
  if (NULL == tkwin){
    /* Appropriate error message here. */
  }
  else{
    Tk_UnmapWindow(tkwin);
    Tk_DestroyWindow(tkwin);
  }

And perhaps this could be wrapped in an appropriate #ifdef.

  This has implications for window reuse. In the case of the .newgame window,
it doesn't really matter, but means that other windows will need to be
recreated from scratch each time they show up in the game.

  My personal opinion is that new users are more likely to be scared off by the
X messages than by a slightly longer delay due to window recreation. This delay
is probably negligible on most modern machines, _not that I am advocating the
neglect of older machines....

  I will make up the necessary patches tomorrow, if I see no serious objections
to this proposal.

  Thanks,
	Eric

Re: [RFC] Possible BadWindow/BadDrawable Fix

[Hans Ronne]

>  So far the only way I have been able to get rid of the BadWindow errors in
>the Tcl/Tk interface on X is to destroy a window after it is withdrawn.
>
>This can be done in tkconq.tcl with:

>Or it can be done in tkmain.c with:

The second solution seems to be the best way if it works.

>And perhaps this could be wrapped in an appropriate #ifdef.
>
>  This has implications for window reuse. In the case of the .newgame window,
>it doesn't really matter, but means that other windows will need to be
>recreated from scratch each time they show up in the game.
>
>  My personal opinion is that new users are more likely to be scared off
>by the
>X messages than by a slightly longer delay due to window recreation. This
>delay
>is probably negligible on most modern machines, _not that I am advocating the
>neglect of older machines....

I don't think it matters under linux, either. But in MacTCL and WinTCL,
performance would suffer. However, if you use #ifdef UNIX things should be
OK.

Hans

[Patch] BadWindow/BadDrawable Fix

[Eric McDonald]

On Fri, 27 Jun 2003, Hans Ronne wrote:

> >Or it can be done in tkmain.c with:
>
> The second solution seems to be the best way if it works.

OK, here is pretty much everything. I still need to think about dealing with
the error and warning dialogs because they use tk_messageBox, but this should
fix (at least it does on my machine) the BadWindow/BadDrawable errors for:
.newgame, .prefs, .find, .contour, .research, .gameover, .meridian, .help,
.scores, .design, and .agreements (even though I know this last window is
currently unused).

I also did a few cosmetic brushups to the Tcl code for the research dialog
since it appeared to be overindented in my editor.

And included is the small patch to tkmap.c that I sent to the list a few days
ago. It never made it into CVS. All it does is remove a compile-time warning.

--- orig-tkconq.h	Fri Jun 27 21:44:21 2003
+++ tkconq.h	Fri Jun 27 21:47:32 2003
@@ -315,6 +315,8 @@

 extern void init_x_signal_handlers(void);	/* Lives in xconq.c. */

+extern int withdraw_window (const char *, Tcl_Interp *);
+
 extern void initial_ui_init(void);
 extern void init_display(void);
 extern void init_redraws(void);

--- orig-tkmain.c	Fri Jun 27 20:22:38 2003
+++ tkmain.c	Fri Jun 27 23:09:09 2003
@@ -195,6 +195,8 @@
 TclCmdFn mapw_cmd;
 TclCmdFn imfsample_cmd;

+TclCmdFn tk_withdraw_window;
+
 void update_mouseover(Map *map, int rawx, int rawy);

 /* Declarations of local functions. */
@@ -346,6 +348,7 @@
     tcl_cmd("get_scores", tk_get_scores);
     tcl_cmd("reset_popup_flag", tk_reset_popup_flag);
     tcl_cmd("exit_xconq", tk_exit_xconq);
+    tcl_cmd("withdraw_window", tk_withdraw_window);

     tkwin = Tk_MainWindow(interp);

@@ -4255,4 +4258,52 @@
 void
 end_printing_forms(void)
 {
+}
+
+int
+tk_withdraw_window( \
+    ClientData cldata, Tcl_Interp *interp, int argc, char *argv[])
+{
+    if (2 > argc){
+        /* TODO: How should we report the error? */
+        return TCL_ERROR;
+    }
+    return withdraw_window(argv[1], interp);
+}
+
+/*
+ * Does the equivalent of "wm withdraw" in Tcl/Tk with the additional
+ *  step of destroying the window on X11 to get rid of the BadWindow messages.
+ */
+int
+withdraw_window (const char * windowpath, Tcl_Interp * interp)
+{
+
+    Tk_Window tkwin = NULL;
+#ifdef UNIX
+    Window xid = 0;
+#endif
+
+    tkwin = Tk_NameToWindow(interp, (char *)windowpath, Tk_MainWindow(interp));
+    if (NULL == tkwin){
+        /* Assume that the user may have closed the window.
+            ...for now, anyway...
+            We may get smarter about this someday.
+        */
+        Dprintf("Could not find window %s.\n", windowpath);
+    }
+    else{
+#ifdef UNIX
+        xid = Tk_WindowId(tkwin);
+#endif
+        Tk_UnmapWindow(tkwin);
+#ifdef UNIX
+        Tk_DestroyWindow(tkwin);
+        Dprintf("Unmapped window %s with XID %x.\n", windowpath, (unsigned)xid);
+#else
+        Dprintf("Unmapped window %s.\n", windowpath);
+#endif
+    }
+    return TCL_OK;
+
 }

--- orig-tkconq.tcl	Fri Jun 27 21:48:30 2003
+++ tkconq.tcl	Fri Jun 27 23:41:09 2003
@@ -1424,7 +1424,7 @@
     }
     launch_game
     # Once the game is underway, we can make this dialog go away.
-    wm withdraw .newgame
+    withdraw_window ".newgame"
 }

 set indepside_up 0
@@ -2928,7 +2928,7 @@
 	    -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
 	    -fg $fgcolor -activeforeground $afcolor -width 8
     button .contour.bottom.cancel -text "Cancel" \
-	    -command { wm withdraw .contour } \
+	    -command { withdraw_window ".contour" } \
 	    -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
 	    -fg $fgcolor -activeforeground $afcolor -width 8
     grid .contour.bottom.cancel .contour.bottom.ok -sticky ew -padx 8 -pady 4
@@ -2936,7 +2936,7 @@
     bind .contour <Key> {
     	if {"%K" == "Escape"} {
 		.contour.bottom.cancel flash
-		wm withdraw .contour
+		withdraw_window ".contour"
 	} elseif  {"%K" == "Return"} {
 		.contour.bottom.ok flash
 		ok_contour_interval
@@ -2952,7 +2952,7 @@
     execute_long_command $map_number($contour_interval_map) \
 	    "map contour-interval=$contour_interval"

-    wm withdraw .contour
+    withdraw_window ".contour"
 }

 set new_meridian_interval 0
@@ -2994,7 +2994,7 @@
 	    -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
 	    -fg $fgcolor -activeforeground $afcolor -width 8
     button .meridian.bottom.cancel -text "Cancel" \
-	    -command { wm withdraw .meridian } \
+	    -command { withdraw_window ".meridian" } \
 	    -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
 	    -fg $fgcolor -activeforeground $afcolor -width 8
      grid .meridian.bottom.cancel .meridian.bottom.ok -sticky ew -padx 8 -pady 4
@@ -3002,7 +3002,7 @@
     bind .meridian <Key> {
     	if {"%K" == "Escape"} {
 		.meridian.bottom.cancel flash
-		wm withdraw .meridian
+		withdraw_window ".meridian"
 	} elseif  {"%K" == "Return"} {
 		.meridian.bottom.ok flash
 		ok_meridian_interval
@@ -3018,7 +3018,7 @@
     set default_map_options(meridian_interval) $new_meridian_interval
     set_map_view_option .m1 meridian_interval

-    wm withdraw .meridian
+    withdraw_window ".meridian"
 }

 # Given a map window, set up all of its standard event bindings.
@@ -3690,7 +3690,7 @@
 }

 proc ask_bool_done { mapn } {
-         wm withdraw .bool
+    wm withdraw .bool
 	destroy .bool
 }

@@ -3877,7 +3877,8 @@
     button .find.bottom.find -text "Find" -command ok_find -default active \
     	-bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
     	-fg $fgcolor -activeforeground $afcolor -width 8
-    button .find.bottom.cancel -text "Cancel" -command { wm withdraw .find } \
+    button .find.bottom.cancel -text "Cancel" \
+        -command { withdraw_window ".find" } \
     	-bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor	\
     	-fg $fgcolor -activeforeground $afcolor -width 8
     grid .find.bottom.cancel .find.bottom.find -sticky ew -padx 8 -pady 4
@@ -3885,7 +3886,7 @@
     bind .find <Key> {
     	if {"%K" == "Escape"} {
 		.find.bottom.cancel flash
-		wm withdraw .find
+		withdraw_window ".find"
 	} elseif  {"%K" == "Return"} {
 		.find.bottom.find flash
 		ok_find
@@ -3907,7 +3908,7 @@
     if { $rslt == 0 } {
 	bell
     } else {
-    	wm withdraw .find
+        withdraw_window ".find"
     }
 }

@@ -3946,16 +3947,17 @@
     frame .research.bottom -bg $bgcolor
     pack .research.bottom -side bottom -fill x
     button .research.bottom.ok -text "Research" -command ok_research \
-        	-bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
-        	-fg $fgcolor -activeforeground $afcolor
+        -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
+        -fg $fgcolor -activeforeground $afcolor
     pack .research.bottom.ok -side left -padx 5 -pady 5
     button .research.bottom.rest -text "Rest" -command rest_research \
-        	-bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
-        	-fg $fgcolor -activeforeground $afcolor
+        -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
+        -fg $fgcolor -activeforeground $afcolor
     pack .research.bottom.rest -side left -padx 5 -pady 5
-    button .research.bottom.cancel -text "Close" -command { wm withdraw .research } \
-        	-bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
-        	-fg $fgcolor -activeforeground $afcolor
+    button .research.bottom.cancel -text "Close" \
+        -command { withdraw_window ".research" } \
+        -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \
+        -fg $fgcolor -activeforeground $afcolor
     pack .research.bottom.cancel -side left -padx 5 -pady 5

     listbox .research.topics -selectmode browse -width 25 \
@@ -4005,12 +4007,12 @@
     	return
     }
     set_side_research $i
-    wm withdraw .research
+    withdraw_window ".research"
 }

 proc rest_research {} {
     set_side_research nothing
-    wm withdraw .research
+    withdraw_window ".research"
 }

 # Create and popup an agreement editing window.
@@ -4131,7 +4133,7 @@
 }

 proc close_agreements_window {} {
-    wm withdraw .agreements
+    withdraw_window ".agreements"
 }

 proc update_agreement_display {} {
@@ -4205,7 +4207,7 @@
 }

 proc dismiss_scores {} {
-    wm withdraw .scores
+    withdraw_window ".scores"
 }

 # Create and popup the preferences dialog.
@@ -4275,7 +4277,7 @@
     bind .prefs <Key> {
     	if {"%K" == "Escape"} {
 		.prefs.bot.cancel flash
-		wm withdraw .prefs
+		withdraw_window ".prefs"
 	} elseif  {"%K" == "Return"} {
 		.prefs.bot.ok flash
 		ok_preferences
@@ -4728,7 +4730,7 @@
 # Make the dialog go away, without altering any preferences.

 proc dismiss_preferences_dialog {} {
-    wm withdraw .prefs
+    withdraw_window ".prefs"
 }

 # Create and popup the help window.
@@ -4994,7 +4996,7 @@
 # Make the dialog go away.

 proc dismiss_help_dialog {} {
-    wm withdraw .help
+    withdraw_window ".help"
 }

 # Game save dialog.
@@ -5108,7 +5110,7 @@
 }

 proc dismiss_game_over_dialog {} {
-    wm withdraw .gameover
+    withdraw_window ".gameover"
 }

 proc disable_move_mode {} {
@@ -5980,7 +5982,7 @@

 proc dismiss_design_palette {} {
     if { "[ winfo exists .design ]" } {
-    	wm withdraw .design
+        withdraw_window ".design"
     }
 }

--- orig-tkmap.c	Fri Jun 27 23:48:29 2003
+++ tkmap.c	Fri Jun 27 23:49:29 2003
@@ -4230,7 +4230,7 @@
 	the interface freeze. */
 	XDrawLines(dpy, d, gc, points, 5, CoordModeOrigin);
     }
-#endif MAC
+#endif /* MAC */

     XFlush(dpy);
     XSetFunction(dpy, gc, GXcopy);

Re: emblem drawing glitches on linux

[Hans Ronne]

>I am in the introductory game, turn 4. I move the unit 1 cell
>NE, everything is ok. Turn 5, I move NE again, but now 5 emblems
>appear briefly in the adjacent cells to the W, NW, NE, E, and SE
>of the unit.  The emblems remain long enough to be visible, then
>they are erased.  I move NE until turn 8 and the above effect
>repeats each turn.  But in turn 8 the next unit is completed, so
>now when I move the first unit NE again, the second unit becomes
>active, and the 5 emblems remain visible around the first unit.
>I move second unit NE.  Turn 9, move second unit NE again, but
>no emblems appear in adjacent cells, like they did for first the
>unit.  Move first unit NE, the emblems quickly appear and
>disappear again.  Turn 10, unit 1 is still active so I move it
>NE.  When the second unit becomes active, the 5 emblems around
>the first unit are again left on the map.

This is something I have never seen, either on Linux, Mac or Windows. We
did have certain redraw problems before I rewrote the unit view code, but
they were of a different kind. And these problems are gone now.

Are the emblems you are seeing that of your own side?

Hans

Re: emblem drawing glitches on linux

[Tom Lowshang]

On Thu, Jun 26, 2003 at 07:34:43AM +0200, Hans Ronne wrote:
> 
> This is something I have never seen, either on Linux, Mac or
> Windows. We did have certain redraw problems before I rewrote
> the unit view code, but they were of a different kind. And
> these problems are gone now.

Unfortunately I have not run cvs update in some months, so I
cannot say if the problem relates to any recent changes.

> 
> Are the emblems you are seeing that of your own side?

Yes, they are. Sorry I forgot to mention that before.

The discussion so far suggests that the problem is specific to
my system (or debian). Does anyone else think this is likely?

Tom

Re: emblem drawing glitches on linux

[Hans Ronne]

>On Thu, Jun 26, 2003 at 07:34:43AM +0200, Hans Ronne wrote:
>>
>> This is something I have never seen, either on Linux, Mac or
>> Windows. We did have certain redraw problems before I rewrote
>> the unit view code, but they were of a different kind. And
>> these problems are gone now.
>
>Unfortunately I have not run cvs update in some months, so I
>cannot say if the problem relates to any recent changes.

That's the first thing to test, then. It is also good to do this is if you
are using TclTk 8.4. Full source compatibility with 8.4 was added just a
few weeks ago.

But I agree that it is most likely a specific issue with your system, since
I never heard of this problem even before the unit view changes.

Hans

Re: emblem drawing glitches on linux

[Tom Lowshang]

The glitches were introduced by the checkin on 2003-05-01, which
is mostly to do with unit views.  This checkin still covers a lot
of code though, so is there anything I can do to narrow it down
further?

Tom

Re: emblem drawing glitches on linux

[Hans Ronne]

>The glitches were introduced by the checkin on 2003-05-01, which
>is mostly to do with unit views.  This checkin still covers a lot
>of code though, so is there anything I can do to narrow it down
>further?

Thanks, that was very useful information. Unfortunately, the new unit view
code was a major change all over the kernel and the interfaces, so it is
difficult to take it apart. However, for technical reasons I doubt that the
problem is with the unit view code itself. Rather, I suspect some other
changes thst were made at the same time. Two things come to mind:

1. There was a change in update_cell (end of tkmap.c) where an "erasing
row" now always is drawn if we see unit views instead of units and unit
names are shown on the map. What happens if you turn off unit names? Do you
still see the glitches? And what happens if you start the game with
see-all? Do they disappear then?

2. There weer also some changes to draw_current which draws the current
unit. What happens if you back out of these changes (if possible) so that
the unit view-specific code is bypassed? One way to achieve thtis is to
change line 3246 in tkmap.c from:

	if (vp->show_all) {

to:

	if (1) {

Hans

Re: emblem drawing glitches on linux

[Tom Low-Shang]

On Sat, Jul 05, 2003 at 02:32:56AM +0200, Hans Ronne wrote:
> 
> 1. There was a change in update_cell (end of tkmap.c) where an
> "erasing row" now always is drawn if we see unit views instead
> of units and unit names are shown on the map. What happens if
> you turn off unit names? Do you still see the glitches? 

Unit names were already off so I tried with unit names on.
There is a small change but the glitches are still there.  The
difference is that the glitch emblems only appear in the W and
NW cells, instead of W, NW, NE, E, and SE cells as they did in
my long turn-by-turn description of the problem.

> And what happens if you start the game with see-all? Do they
> disappear then?

Yes! The problem goes away completely.

> 
> 2. There weer also some changes to draw_current which draws
> the current unit. What happens if you back out of these
> changes (if possible) so that the unit view-specific code is
> bypassed?

No glitch emblems!  This looks promising.  Let me know if there
is anything else you would like me to try.

Tom

Re: emblem drawing glitches on linux

[Hans Ronne]

>Unit names were already off so I tried with unit names on.
>There is a small change but the glitches are still there.  The
>difference is that the glitch emblems only appear in the W and
>NW cells, instead of W, NW, NE, E, and SE cells as they did in
>my long turn-by-turn description of the problem.

OK. That's because the name erasing code in part erases your glitch.

>> And what happens if you start the game with see-all? Do they
>> disappear then?
>
>Yes! The problem goes away completely.
>
>>
>> 2. There weer also some changes to draw_current which draws
>> the current unit. What happens if you back out of these
>> changes (if possible) so that the unit view-specific code is
>> bypassed?
>
>No glitch emblems!  This looks promising.  Let me know if there
>is anything else you would like me to try.

I'm not 100% sure whay the problem is yet, but perhaps you could try this
patch in draw_current:

	if (vp->show_all) {
	    x_xform_unit_self(mapw, unit, &sx, &sy, &sw, &sh);
	} else if (uview) {
	    rslt = x_xform_unit_self_view(mapw, uview, &sx, &sy, &sw, &sh);
	    /* This may be called while there is no view object for
	       the current unit, such as while updating the display
	       when the unit moves and is "between" cells. */
	    if (!rslt)
	      return;
+	} else {
+	    return;
	}

Hans

Re: emblem drawing glitches on linux

[Tom Low-Shang]

On Sat, Jul 05, 2003 at 10:25:51AM +0200, Hans Ronne wrote:
> I'm not 100% sure whay the problem is yet, but perhaps you could try this
> patch in draw_current:
> 
> 	if (vp->show_all) {
> 	    x_xform_unit_self(mapw, unit, &sx, &sy, &sw, &sh);
> 	} else if (uview) {
> 	    rslt = x_xform_unit_self_view(mapw, uview, &sx, &sy, &sw, &sh);
> 	    /* This may be called while there is no view object for
> 	       the current unit, such as while updating the display
> 	       when the unit moves and is "between" cells. */
> 	    if (!rslt)
> 	      return;
> +	} else {
> +	    return;
> 	}

The glitch emblems do not appear when I make the above changes.

Tom

Re: emblem drawing glitches on linux

[Hans Ronne]

>The glitch emblems do not appear when I make the above changes.

Excellent. This was clearly a bug, even if it had no effects for most
people. I will check in the fix. Thanks for your help in debugging it.

Hans

Re: emblem drawing glitches on linux

[Hans Ronne]

>Hi all, my first post to this list.  With so few posters here,
>how could anyone _not_ notice a first post? :-)
>
>When moving a unit, I can see emblems being drawn and erased in
>adjacent cells if at least one of those cells has not been seen
>before.  If another unit becomes active, then the emblems around
>first unit remain on the map.  There are other cases where the
>emblems remain, but I can't quite figured the pattern out.  I
>can erase the extra emblems by redrawing the map, so they are
>really just a visual nuisance.  Everything works fine otherwise.

Welcome to the list! It's always nice to get user feedback.

I'm not sure I understand the problem you describe, though. Do you mean
that you see emblems without units being drawn? That would be strange
indeed, unless you have turned on "View People" or "View Control", both of
which use emblems without units to denote borders. OTOH, if you are talking
about unit-associated emblems, they should always be drawn, whether the
unit is active or not.

A possible complication if you are using linux is that you have two
versions of xconq: an obsolete installed version and a current CVS version.
Even if you build and run the CVS version, it may still use the installed
libraries and tcl scripts if that is where XCONQLIB points on your system.
This is a frequent source of problems since the tcl scripts of one version
of xconq seldom are completely compatible with another version.

Hans

Re: emblem drawing glitches on linux

[Tom Lowshang]

On Thu, Jun 26, 2003 at 12:42:45AM +0200, Hans Ronne wrote:
> 
> I'm not sure I understand the problem you describe, though. Do
> you mean that you see emblems without units being drawn? That
> would be strange indeed, unless you have turned on "View
> People" or "View Control", both of which use emblems without
> units to denote borders. OTOH, if you are talking

Yes the emblems appear without units. View People and View
Control are both off, but the extra emblems are appearing in
border cells.  See my long turn by turn description in another
mail.

> about unit-associated emblems, they should always be drawn,
> whether the unit is active or not.

Unit enblems are ok.

> 
> A possible complication if you are using linux is that you
> have two versions of xconq: an obsolete installed version and
> a current CVS version.  Even if you build and run the CVS
> version, it may still use the installed libraries and tcl
> scripts if that is where XCONQLIB points on your system.  This
> is a frequent source of problems since the tcl scripts of one
> version of xconq seldom are completely compatible with another
> version.

Only the CVS version is installed.  Just to be safe, I removed
the install directory to ensure no stale files existed, and ran
make install again, but it did not help.

Tom