nanogui: NanoGUI palette model
Subject:
RE: NanoGUI palette model
From:
Greg Haerr ####@####.####
Date:
30 Sep 1999 20:27:55 -0000
Message-Id: <01BF0B4F.968DCAA0.greg@censoft.com>
: BTW, you pulled this topic off the list - was that intentional?
No
:
: Anyway, I'm wondering: since the middle layer is flipped (BGR) to help the
: Microwin layer be directly compatable with Win32 ordering, that means that
: all non-Microwin top layers will have to a) either adopt the bogus window
: BGR ordering, or b) use real RGB and flip it for the middle layer. Do you
: think maybe it would be better to make Microwin flip so that others don't
: have to? I know that there really aren't "others", but if more come, RGB
: ordering seems more natural than BGR ordering.
:
: Here's another way of putting it: I think it might be more digestible to
: consume "Windows is backwards" than "MicroGDI is backwards" (even though you
: and I both know that it is all relative).
:
This is really a very small issue. There are countless ways
to organize data. I just chose one way.
BTW, it isn't backwards. Consider the structure defined in device.h:
typedef struct {
char r;
char g;
char b;
};
When this struct is laid down in ram (for instance in a longword)
on a little-endian machine (all intel and mips) then the byte order you get is
exactly the order that you think is backwards. This allows the palette
entries (RGB values) to be read using an old-fashioned (nonportable) C trick without
calling a function:
rgbval = (*(unsigned long *)&rgbentry) & 0xFFFFFF;
Greg
