GB> RB> Does anyone know where information on the DIVE spec can be found that i
GB> RB> more complete than what is available in the DIVE.ZIP file?  I am
GB> RB> specifically wondering about hardware palette management calls.  I have
GB> RB> seen DLIB06's solution to the 8-bit color palette problem, but it only
GB> RB> works for VGA cards.  I figure DIVE must have something built in.

GB>My 8-bit color method used in DLIB, is virtually what
GB>happens when you set up a palette into a HPS, ie generates
GB>a conversion table. This is how the PM video drivers do it.
GB>16bit and 24bit color have a hardwired palette.

It would be nice if you could create a palette and have it loaded into
hardware as is though, then the drawing routines could be way faster.
The other option is to make a conversion table and fiddle every bitmap
in your system to conform to the hardware palette.  Another time waster.
For a game with a zillion textures like doom, this would be really
slow. I have seen this method used on a doom-style graphics engine
called wt and the colors are funny.  It just doesn't look right.

GB>Don't be suprised if you see a library from IBM to handle simple palette, an
GB>clipping problems. I seem to be the only other person that
GB>fully understands it. If my video drivers supported >8bit
GB>color, I too would support it in DLIB.

I have heard that this is on the way, along with image stretching and a
few other goodies in MMPM in performance beta II.  Oh, in DLIB you get
the hardware palette through port IO, you can get the same info using
the GpiQueryRealColors function.

Rob.
___
 X SLMR 2.1a X I haven't lost my mind...it's backed up on tape somewhere

--- Maximus/2 2.01wb