[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
PIXEL565TOCOLORVAL
From: Jamie Guinan ####@####.#### Date: 31 Jul 2000 10:18:20 -0000 Message-Id: <Pine.LNX.4.21.0007310542310.994-100000@gemini.home.net> (microwindows-0.88pre11) In include/device.h, we have, /* create 16 bit 5/6/5 format pixel from RGB colorval (0x00BBGGRR)*/ #define COLOR2PIXEL565(c) \ ((((c) & 0xf8) << 8) | (((c) & 0xfc00) >> 5) | (((c) & 0xf80000) >> 19)) This takes the 5 high bits of RR and packs them into the red component of the 16-bit value. Similar for GG and BB. Then we have, /* create RGB colorval (0x00BBGGRR) from 5/6/5 format pixel*/ #define PIXEL565TOCOLORVAL(p) \ ((((p) & 0xf800) >> 11) | (((p) & 0x07e0) << 3) | (((p) & 0x1f) << 16)) This seems to take the 5 bits of the red component and shift them into the *low* bits of RR. Similar for green and blue. Shouldn't the latter macro go, #define PIXEL565TOCOLORVAL(p) \ ((((p) & 0xf800) >> 8) | (((p) & 0x07e0) << 5) | (((p) & 0x1f) << 19)) so that PIXEL565TOCOLORVAL(COLOR2PIXEL565(p)) = p ? Or more precisely, ... = (p & 0xF8FCF8) FYI, I bumped into this while working on a driver for an Epson SED1356 development board. It has a little endian memory mapping, so the 5/6/5 layout actually becomes 3/5/5/3 (G-low/B/R/G-high) when plugged into my PowerPC target system (MBX/821). The development board has a switch for big-endian mode, but the control register addresses get byte-swapped as a side-effect, so it seemed less work to write a new set of macros for "MWPF_TRUECOLOR565LE" then reworking the driver code. ^^ Any better ideas are welcome. -Jamie p.s. I just noticed, the PIXEL565* macros need similar fixing if they are intended to return 8-bit values instead of 5/6 bit component values. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: PIXEL565TOCOLORVAL
From: "Greg Haerr" ####@####.#### Date: 2 Aug 2000 04:05:43 -0000 Message-Id: <001401bffc36$ec3fc920$15320cd0@gregh> Jamie, Sorry I took so long to reply. I've been busy, and as well, as long as it took to come up with the PIXEL/COLOR macros in the first place, I needed to make sure that I had enough quiet time to study them, since they're a real mind-twister to get right. And, you're right! The PIXEL565TOCOLORVAL macro shifts the 5/6/5 values into the LOW BGR color positions, rather than using the full 8 bits per RGB. Also, the PIXEL565RED* macros return the 5/6 bit component values, rather than the correct 8 bit values. Great catch, thanks for the inspection. Would you like me to fix them, or have you fixed them and tested them. Perhaps with reason, I can't get 16bpp color working on my system... I see we've got the same problems with PIXEL332 as well. The PIXEL888 macros are correct. : so it seemed less work to write a new set of macros for : "MWPF_TRUECOLOR565LE" then reworking the driver code. : ^^ : Any better ideas are welcome. I think the macros are a good idea. Yes, we only handle the BGR oriented rgb stuff, we probably need another set of macros for the RGB rgb stuff.... Regards, Greg : (microwindows-0.88pre11) : : In include/device.h, we have, : : /* create 16 bit 5/6/5 format pixel from RGB colorval (0x00BBGGRR)*/ : #define COLOR2PIXEL565(c) \ : ((((c) & 0xf8) << 8) | (((c) & 0xfc00) >> 5) | (((c) & 0xf80000) >> 19)) : : This takes the 5 high bits of RR and packs them into the red component : of the 16-bit value. Similar for GG and BB. : : Then we have, : : /* create RGB colorval (0x00BBGGRR) from 5/6/5 format pixel*/ : #define PIXEL565TOCOLORVAL(p) \ : ((((p) & 0xf800) >> 11) | (((p) & 0x07e0) << 3) | (((p) & 0x1f) << 16)) : : This seems to take the 5 bits of the red component and shift them : into the *low* bits of RR. Similar for green and blue. : Shouldn't the latter macro go, : : #define PIXEL565TOCOLORVAL(p) \ : ((((p) & 0xf800) >> 8) | (((p) & 0x07e0) << 5) | (((p) & 0x1f) << 19)) : : so that PIXEL565TOCOLORVAL(COLOR2PIXEL565(p)) = p ? : : Or more precisely, ... = (p & 0xF8FCF8) : : FYI, I bumped into this while working on a driver for an Epson SED1356 : development board. It has a little endian memory mapping, so the 5/6/5 : layout actually becomes 3/5/5/3 (G-low/B/R/G-high) when plugged into my : PowerPC target system (MBX/821). The development board has a switch for : big-endian mode, but the control register addresses get byte-swapped as : a side-effect, so it seemed less work to write a new set of macros for : "MWPF_TRUECOLOR565LE" then reworking the driver code. : ^^ : Any better ideas are welcome. : : -Jamie : : p.s. : I just noticed, the PIXEL565* macros need similar fixing if they are : intended to return 8-bit values instead of 5/6 bit component values. : : : --------------------------------------------------------------------- : To unsubscribe, e-mail: ####@####.#### : For additional commands, e-mail: ####@####.#### : : | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |