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