nanogui: More on 16-bit color, and more
Subject:
RE: More on 16-bit color, and more
From:
Greg Haerr ####@####.####
Date:
4 Jan 2000 17:46:14 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFBEFF4@NBA-SLAM.CenSoft.COM>
: In device.h a simple test for __PIXEL16__ selects 16-bit PIXELVAL
: if defined.
This is fine, but I like your SCREEN_PIXTYPE idea below better.
:
: The last patch to nanox/client.c is a portability issue as I have
: mentioned before. If someone knows what ANSI-C/standard-C has to
: say about sizeof(*(void *)) WRT pointer arithmetic, I'm all ears;
: my impression is that GNU-C has made its own standard in this
: respect that may not port well?
I applied this patch when you first sent it long ago, figuring
you were correct that (void *)++ doesn't always increment
by 1.
:
: As to how microwin should be updated to support different PIXELVAL
: sizes, I have the following suggestion:
:
: #if SCREEN_PIXTYPE == PF_TRUECOLOR24
: typedef unsigned long PIXELVAL;
: #define RGB2PIXEL(r,g,b) RGB2PIXEL24(r,g,b)
: #define PIXEL2RGB ...
: #endif
:
: #if SCREEN_PIXTYPE == PF_TRUECOLOR565
: typedef unsigned short PIXELVAL;
: #define RGB2PIXEL(r,g,b) RGB2PIXEL565(r,g,b)
: #define PIXEL2RGB ...
: #endif
:
: etc.
:
: This will separate the various modes into nice sections that should be
: easily maintainable and understandable. They can also be easilly
: extended by adding new sections. Testing for various other build
: targets can be done at the beginning of the file; e.g. forcing
: SCREEN_PIXTYPE to PF_PALETTE if __AS386_16__ is defined.
:
: The test in GrArea for pixtype support can be a test against
: SCREEN_PIXTYPE.
:
: I can write the patch itself if you think this is a good idea?
Sure, go ahead. I like it. Since PIXELVAL needs to be defined
early on, you might want two separate sections in device.h
for the #if testing, so that all the RGB color stuff doesn't get
dragged to the top of the file... I try to keep the type declarations
ahead of all the macros.
Regards,
Greg
