nanogui: NanoGUI palette model
Subject:
RE: NanoGUI palette model
From:
Greg Haerr ####@####.####
Date:
29 Sep 1999 17:26:57 -0000
Message-Id: <01BF0A6D.26802AB0.greg@censoft.com>
: It doesn't have to be complicated. GdFindColor just has to know how to
: map a 24 or 32 bit RGB value to the main types of RGB displays:
: 15/16/24/32 bits with different byte ordering. It can either be part of
: GdFindColor, or we can add a function to the drivers to do it. If we're
: going to support truecolor on all kinds of hardware it's something we'll
: have to deal with anyway. Normally you just want to strip the least
: significant bits and organize them correctly withing the 32 bit value.
I say just put the code in GdFindColor for now. This function is
responsible for converting a COLORVAL to a PIXELVAL. It would be fairly
easy to separate the 24/32 bit value to 15/16/24/32 bits. I started with the
#ifdef TRUECOLOR, but cant' test anything cause I can't get the damned
framebuffer to run 32 bits... (And we don't yet have a real-mode 640x480x256
driver)
: Yes, but currently, if TRUECOLOR is defined, it doesn't let you use the
: palette - GdFindColor() just returns whatever value it's passed in and
: assumes that COLORVAL == PIXELVAL for truecolor displays. First of all,
: that isn't true for any displays that doesn't organize their color values
: the same way COLORVAL's are, second it means that any code that rely on
: palette indices won't work on truecolor displays at all, as far as I can
: understand.
I agree. #defining TRUECOLOR isn't implemented, really, I just
stuck it in to point to where the work is needed. Let's implement as you
suggest, we can't assume that COLORVAL==PIXELVAL. I suggest
adding another entry in the scrdev structure that indicates the way that
the hardware PIXELVALs are packed, and the devdraw.c code can pack
them according to the enum: PACKED15, PACKED16, PACKED24, PACKED32,
or any other crazy format.
: >Definitely. The design is that user programs will run unmodified on
: >various hardware, without knowledge of it. That's why I chose RGB. F_PALINDEX
: >is of limited usefulness, but is quite fast and the standard colors defined
: >in device.h
: >all work on any device.
:
: Does it? In GdFindColor(), if TRUECOLOR is defined and the driver returns
: a SCREENINFO structure that states that more than 256 colors are available,
: it just casts the COLORVAL to PIXELVAL and returns it.
This needs fixing as stated above.
So if it is passed
: a palette index, you'll get "RGB" values of the type (F_PALINDEX | index),
: which certainly won't map to the right color. Or is there something I've
: overlooked?
You're right. Ultimately, I suggest *not* using palette indexes in
application programs. I only added it so that you _can_ have it if you really
want it, _and_ know what hw you're running on. Normally, all apps, including
widgets, should use RGB schemes only. This means that we should have
a separate color definition file for BLACK, BLUE, WHITE, etc. --OR-- we
always use F_PALINDEX colors by reading their RGB entry from the linked
in devpalX.c, and then use the above algorithm.
:
: What I'm suggesting is only that if TRUECOLOR is defined that we get the
: RGB value from the palette if F_PALINDEX is set, so that palettes (including
: user defined) work on truecolor displays too.
:
OK. - I agree.
Greg
