Hi !
> > Either it is uint32 for 32 bit wide modes, or something like
> > struct rgb { unsigned char r,g,b;} for 24 bit wide ones.
> ok. But the step size from one pixel to the next is different. how can the
> result be the same when I either use a uint32 or the 24 bit struct?
It's either-or as in "the hardware says what you got to use".
Examine the size entry in the directbuffer descriptor.
> Is this handled by the hardware?
No, the hardware cannot guess what you want to achieve.
> > No, you incrementally write 1,2,3,... into the red, green, blue, red, ...
> > components, which gives more or less a grey caolor value, as the red, green
> > and blue components of a pixel always have values that are just apart by one.
> I write 8 bits at once. You mean that in true color mode I write 4
> loop circels (of the inner loop) in the same pixel.
Yes. With each of those four round writing one color component (and a dummy
that is used to pad stuff to 32 bits).
> > > It should depend only on the number of pixels/row and their color depth.
> > No. It can depends on alignment and other hardware restrictions.
> bad.
No - as said, you don't need to care about it. You just use the values form
the directbuffer descriptor and that's it.
> To resum: in true color mode I step from one pixel to the other by adding
> the size of either uint32 or sizeof( struct....) to pixelPointer.
To be precise: By adding pixelformat->size/8 bytes.
> When I've reached the last pixel of the row and want to jump into the
> next row I have to calculate the jump size with
(uint8 *)pixelPointer += stride;
This brings you one pixel down. If you already walked with the pixelPointer,
you have to compensate like this:
(uint8 *)pixelPointer += stride - already_walked_bytes;
> > Have a look at ggi.h, line 161ff.
> Don't you think this should be written in a documentation?
Basucally yes, but to work with directbuffers, it's pretty important anyway
to thoroughly familiarize yourself with the structs that describe the DB.
So we didn't bother placing it somewhere else as well.
> Ok if I do
> x = 255;
> *pixelPointer = x << 16;
> I get what color? pure red?
That depends on your hardware. If you want pure red, you'll have to:
*pointer &= ~(green_mask|blue_mask|red_mask); // Mask out old bits
*pointer |= (0xffffffff>>shift) & red_mask;
That's the generic way. Of course you only have a few common formats, that
you can check for once and the use a more efficient method.
> This means I don't allocate colors and I don't need ggiSetPalett and the
> like, right?
Yes. You only need a palette when SetMode indicated that it uses a palettized
mode. You check like this:
if (GT_SCHEME(mode.graphtype) == GT_PALETTE) {
ggiSetColorfulPalette(vis);
ggiGetPalette(vis, 0, 1<<depth, pal);
}
> I simply write in the direct buffer and make a ggiFlush.
Yes.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
