Re: [AD] problem with Chris' X primitives patch

[Chris <kcat@xxxxxxxxxx>]

Peter Wang wrote:
> Chris' patch breaks exjoy (major flickering and doesn't work right) and 
> exspline (the walking circle leaves trails which it shouldn't) on my 
> system (X server 32 bpp colour depth).  With the patch removed both 
> programs work fine.

This is odd. I unfortunately can't test exjoy since I don't have a 
working joystick, but I do see a problem with exspline. It appears that 
the problem is this: XPutImage is paying attention to the drawing mode 
(XOR in this case). Since the image is being (properly) XOR'd onto the 
memory bitmap, then (improperly) XOR'd again onto the screen, it comes 
out wrong. Allegro doesn't apply the current draw mode when blitting, so 
it threw me off.

The attached patch fixes the exspline problem.

But it seems I've possibly stumbled across a more general problem. Is 
gfx_driver->drawing_mode called when a new video mode is set, or is the 
drawing mode reset when a mode is changed? If not, the driver may lose 
the current drawing mode and start producing wrong results when it's reset.

I'll look through exjoy.c and see if I can find any problem that would 
cause flickering.

- Kitty Cat

Index: src/x/xvtable.c
===================================================================
RCS file: /cvsroot/alleg/allegro/src/x/xvtable.c,v
retrieving revision 1.12
diff -u -r1.12 xvtable.c
--- src/x/xvtable.c	18 Aug 2004 13:03:45 -0000	1.12
+++ src/x/xvtable.c	29 Aug 2004 04:59:48 -0000
@@ -66,6 +66,11 @@
 {
    int gc_func;
 
+   if (!_xwin.matching_formats) {
+      XSetState(_xwin.display, _xwin.gc, 0, 0, GXcopy, -1);
+      return;
+   }
+
    if(_drawing_mode == DRAW_MODE_SOLID)
       gc_func = GXcopy;
    else if (_drawing_mode == DRAW_MODE_XOR)