No, sorry. It may be a bug (there are lots in the Win32 port at the moment). Can you provide a small test case? (I have never used the grx bgi interface).

It's not in the bgi-interface, it's just a bug in GRX-Win32. Example code:

MINGW>gcc -c grxbug.c -g -O3 -W -Wall -Ic:\djgpp\contrib\grx24\include MINGW>gcc grxbug.o -o grxbug.exe c:\djgpp\contrib\grx24\lib\win32\libgrx20.a -mwindows -mconsole

grxbug.c:

#include <stdio.h> #include <stdlib.h> #include <conio.h> #include <grx20.h> #include <grxkeys.h>

#ifdef __WIN32__ int GRXMain() //int argc, char **argv) #else int main() //int argc, char **argv) #endif { GrMouseEvent ev; int i; GrColor *ega; int x,y; char s[2];

GrSetDriver("VESA gw 800 gh 600 nc 256"); GrSetMode(GR_default_graphics); GrMouseInit(); GrClearScreen(GrWhite()); ega=GrAllocEgaColors(); y=20;x=200; //This should paint a series of 'dots' and 'bars' in XOR colors for(i=0;i<16;i++) { GrLine(x,y,x+200,y,GrXOR|ega[i]); GrLine(x,y+1,x+200,y+1,GrXOR|ega[i]); GrLine(x,y-1,x+200,y-1,GrXOR|ega[i]); GrPlot(x-10,y,GrXOR|ega[i]); GrPlot(x-10,y+1,GrXOR|ega[i]); GrPlot(x-10,y-1,GrXOR|ega[i]); GrPlot(x-11,y,GrXOR|ega[i]); GrPlot(x-11,y+1,GrXOR|ega[i]); GrPlot(x-11,y-1,GrXOR|ega[i]); GrPlot(x-12,y,GrXOR|ega[i]); GrPlot(x-12,y+1,GrXOR|ega[i]); GrPlot(x-12,y-1,GrXOR|ega[i]); y+=20; } for(i=0;i<16;i++) { GrLine(0,0,0,0,ega[i]);//comment this line (kindof dirty workaround) } GrMouseDisplayCursor(); do { GrMouseGetEvent(GR_M_EVENT,&ev); } while(!(ev.flags&GR_M_KEYPRESS));

exit(EXIT_SUCCESS); }

If you comment out the marked line the bug with XOR becomes obvious. But even with that 'dirty workaround' enabled you will see some strange effect when you move the cursor slowly over the graphics: some pixels change their color when under the arrow, others don't. And please note that the colors from the GrPlot() calls ar not equal to those from GrLine() calls, as they should.

Perhaps somebody knows a way how to approach that problem. Thanks.