On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote:
> ggi provides a ggiPackColors routine, which internally has to map the
> colors of the array. so why does not ggi provides a ggiPackPixels
> routine?
Because "ggi_pixels" are already considered to be packed. You can't
pack them any further... the only thing you can do is to translate them
into pixels of a different pixelformat. That's what crossblit does,
between visuals, and it is what the (Un)Map/Pack function pairs are there
for as well.
ggi_pixel may be defined as a uint32, but that is just so it will fit
all values that a "pixel" can have for any fb depth up to 32 bits,
which is the maximum depth LibGGI currently supports. (There is
nothing beyond binary compatibility preventing us from someday
deciding that we want to change ggi_pixel to be a uint64, or in an
embedded system it could be a uint16 to save space. You should
not rely on sizeof(ggi_pixel) staying constant. The whole reason we
use ggi_pixel instead of just uint32 is so that people know not to
assume it is a uint32)
When you are dealing with a 8bpp buffer, your pixel values are
actually just uint8's. Notice that the PackColors function doesn't
return an array of ggi_pixels, but a void *, because if you pack 16
colors, you'll get 16 bytes of pixel data back if v is a 8bpp visual,
you'll get 32 bytes of data if v is a 15 or 16bpp visual, etc.
Not even all the ggi_pixel's which actually use all 32 bits of the
uint32 are the same... they can vary based on the visual's pixelformat
and have different meanings, like for example, they can have rgb or
bgr ordering on the bits that are used.
> it seems it would be much more efficient, and easier/shorter
> to implement than ggiPackColors. any particular design reason?
What you are asking is for GGI to define a "standard" 32 bit
pixelformat and define functions to operate on that pixelformat. GGI
isn't in the business of defining arbitrary standards... everything in
the API has been distilled to avoid doing something like that.
The most direct way to do what you want to do would be to just render
your glyphs in 8bpp grayscale, and then render a palette to the visual,
and get it back out with getbox, then when you want to look up a color
when you are rendering, do this:
switch (db->buffer->size) {
case 8:
for (fx = 0; fx < fontwidth; fx++) {
for (fy = 0; fy < fontheight; fy++) {
((uint8 *)buf)[fx + fy + fontwidth] =
((uint8 *)pal)[((fgcolor * numcolors + bgcolor) * numcolors)
* 256
+ glyph[fx + fy * fontwidth]]
}
}
break;
case 16:
/* as above but using (uint16 *) */
case 24;
/* more complex code to pack to 24 bits */
case 32:
/* as above but using (uint32 *) */
}
ggiPutBox(v, xpos, ypos, fontwidth, fontheight, buf);
... or if that consumes too much memory just cache the more commonly
used colors and generate the rest on the fly.
The other solution was to operate on a memory visual with a known 32 bit
pixelformat and use crossblit. In that case, you'll just need code to add
the colors to the 8bpp grayscale via a formula that produces 32bpp values,
and load the results into the 32bpp memvisual.
--
Brian
