nanogui: PIXEL565TOCOLORVAL
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: ####@####.####
:
:
