> > What causes the overrun? The wrong usigned typ?
>
> Sort of. The main problem is the larger size combined with the wrong
> stride-compensation mentioned below.
aha.
> > What type should directBuffer be if I want to have truecolor?
>
> 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? Is
this handled by the hardware?
> 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. Actually it maps a piece of shared memory that the X server will blit
> to the window at ggiFlush() time.
So only a 256 x 255 pixel area.
>
> > 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.
> > But if used with the X target stride would have the number of pixel *
> > colordepth of only the window. Is that correct?
>
> Yes. However you should not worry about how the value is generated.
> Just use 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. 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
pixelPointer += stride - mode.virt.x;
(when stride was calculate as you suggested)
Was that right?
>
> > If I choose pixelPointer long unsigned or uint32 then I'll have to do the
> > same with for x.
> >
> > Don't understand this. Why should I shift x 0, 8, 16 bits to the left?
>
>
> To access the right parts of the color mapping.
arghh!
> However, of course the
> right way of doing this is to use the red/green/blue_mask/shift values for
> doing it.
>
> Have a look at ggi.h, line 161ff.
Don't you think this should be written in a documentation?
Ok if I do
x = 255;
*pixelPointer = x << 16;
I get what color? pure red?
x = 255;
*pixelPointer = x;
pure blue?
> Something like it. depends on endianness of the graphics board. The above
> method automatically takes care of it.
ok.
>
> Because you are accessing 32 bit wide data with 8 bit wide accesses. The
> increments are too small.
guess I understand that now.
> Of course, when you are in a true color mode. But when in true color mode,
> you need no palette.
>
This means I don't allocate colors and I don't need ggiSetPalett and the
like, right? I simply write in the direct buffer and make a ggiFlush.
gr. matthias
