Hi, Alex
About the drawstrg bug.
It isn't (and if it were a bug the correct place to check is in the
fdriver, because it must know how to get the color from a GrColor variable).
The problem is in the test program. GrAllocEgaColors must be placed_after_ GrSetMode.
the problem is in the test program indeed. the bug appears when printing to a ram context, as in the example i submit here now. the order between the 2 function calls is irrelevant, examine GrAllocEgaColors.
At last I can see the bug. You are correct.
The bug only occurs in 4bpp mode, so this is why I didn't see it before, and why I thought it was the GrAllocColor order. Try: egacolors = GrAllocEgaColors(); GrSetMode(GR_width_height_bpp_graphics, 640, 480, 24); to see what happen.
But the line ctx = GrCreateFrameContext(GR_frameRAM4, w * 16, h * 16, NULL, NULL); in your second test clearly identify the problem. (By the way this code is not safe, you must use GrCreateContext in normal programs).
The bug is in src/fdrivers/ram4.c, here is a patch to solve it:
--- ram4.old Mon Nov 6 03:41:18 2000 +++ ram4.c Wed Oct 23 22:28:22 2002 @@ -58,7 +58,7 @@ offs = FOFS(x,y,CURC->gc_lineoffset); mask = 0x80 >> (x &= 7); cval = (unsigned int)color << (7 - x); - switch(op = C_OPER(color)) { + switch(op = C_OPER(color) & 3) { case C_WRITE: case C_AND: CURC->gc_baseaddr[0][offs] &= ((cval ) | ~mask);
Thanks a lot Alex
Regards, M.Alvarez