GRX 2.4.8/DJGPP ; GrDrawString(void *text,int length,int x,int y,const GrTextOption *opt); - when opt->txo_font.txo_fgcolor.v = 0x10000000 | GrXOR then the underline flag (0x10000000) causes the XOR operation flag to stop functioning, and behave like GrWRITE. Maybe GRX is accidently reseting the GrXOR flag instead of the GrXOR<<4 (underline) flag? Can anyone confirm? Fixes? Reply to haidera@australia.edu
Al-Junaid H. Walker a écrit:
GRX 2.4.8/DJGPP ; GrDrawString(void *text,int length,int x,int y,const GrTextOption *opt);
- when opt->txo_font.txo_fgcolor.v = 0x10000000 | GrXOR then the underline flag (0x10000000) causes the XOR operation flag to
stop functioning, and behave like GrWRITE. Maybe GRX is accidently reseting the GrXOR flag instead of the GrXOR<<4 (underline) flag? Can anyone confirm? Fixes? Reply to haidera@australia.edu
Indeed. It seems that underlining was an after thought, with no full appreciation of all the consequences. Try the following patch
-----------------------------------------------------------------------
--- src/include/libgrx.h.orig 2007-03-08 20:28:00 +0000 +++ src/include/libgrx.h 2008-05-15 10:02:14 +0000 @@ -295,11 +295,11 @@ int _GrResetColors(void); /* like GrResetColors but return true on success */
#ifdef __TURBOC__ -# define C_OPER(color) (unsigned int)(((unsigned char *)(&(color)))[3]) +# define C_OPER(color) (unsigned int)(((unsigned char *)(&(color)))[3] & 15) #endif
#ifndef C_OPER -#define C_OPER(color) (unsigned int)((GrColor)(color) >> 24) +#define C_OPER(color) (unsigned int)(((GrColor)(color) >> 24) & 15) #endif #define C_WRITE (int)(GrWRITE >> 24) #define C_XOR (int)(GrXOR >> 24)
----------------------------------------------------------------------
It works for me for djgpp/vesa I need to check it for other targets/drivers. Since they have been written by different authors, the solution may be different.
Maurice
Maurice Lombardi a écrit:
Al-Junaid H. Walker a écrit:
GRX 2.4.8/DJGPP ; GrDrawString(void *text,int length,int x,int y,const GrTextOption *opt);
- when opt->txo_font.txo_fgcolor.v = 0x10000000 | GrXOR then the underline flag (0x10000000) causes the XOR operation flag to
stop functioning, and behave like GrWRITE. Maybe GRX is accidently reseting the GrXOR flag instead of the GrXOR<<4 (underline) flag? Can anyone confirm? Fixes? Reply to haidera@australia.edu
Indeed. It seems that underlining was an after thought, with no full appreciation of all the consequences. Try the following patch
--- src/include/libgrx.h.orig 2007-03-08 20:28:00 +0000 +++ src/include/libgrx.h 2008-05-15 10:02:14 +0000 @@ -295,11 +295,11 @@ int _GrResetColors(void); /* like GrResetColors but return true on success */
#ifdef __TURBOC__ -# define C_OPER(color) (unsigned int)(((unsigned char *)(&(color)))[3]) +# define C_OPER(color) (unsigned int)(((unsigned char *)(&(color)))[3] & 15) #endif
#ifndef C_OPER -#define C_OPER(color) (unsigned int)((GrColor)(color) >> 24) +#define C_OPER(color) (unsigned int)(((GrColor)(color) >> 24) & 15) #endif #define C_WRITE (int)(GrWRITE >> 24) #define C_XOR (int)(GrXOR >> 24)
It works for me for djgpp/vesa I need to check it for other targets/drivers. Since they have been written by different authors, the solution may be different.
It seems OK also for win32 x11 sdl I uploaded it to the section "more things" in the GRX site.
Maurice