Hi !
> > This is very probably caused by overrunning the buffer. See below as well.
> 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.
> 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.
> > Yes and no. If you have set a truecolor mode, and then draw a "color bar"
> > using 8 bit wide data, the rrggbb-Data of a pixel will look like 010203
> > or similar, which is more or less grey.
> You mean the leftward bits get truncated.
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.
> > Yeah - the kgicon target maps the whole buffer thus allowing for overruns.
> And what does the X target map? Only the buffer belonging to the window?
Yes. Actually it maps a piece of shared memory that the X server will blit
to the window at ggiFlush() time.
> How should this be done for true color?
> stride = directBuffer->buffer.plb.stride / sizeof( uint32 );
I'd do it the other way round, as it would allow for the strange case where
lines are not aligned to the native pixel size, though I don't think that
happens on any target. But other than that: right.
> I took it from slimy.c. I wondered how I can draw in exactly that part of
> the frame buffer where I would hit the area of the displayed window (using
> X11). Do I guess right that the direct buffer starts at the top left
> corner (with the kgicon target)?
Yes. Actually I think we should specify this somewhere and also provide for
an "x-stride". This allows for tilting the image to our liking.
> Obviously I don't know the window position,
If you want to know, that's what LibWMH is for. Hmm - good point. Got to
update it to reflect Marcus' changes on the extension mechanism.
Marcus: just prod me a little from time to time ...
> that's why I guess on the X Target the frame buffer is restricted to the
> window.
Yes.
> But what size does stride then have?
> stride represents the size of one row of the screen in bytes, right?
Yes. Or to be precise, it represents the distance between the same colum
in two consecutive lines. I.e. the number of bytes to add to step "down".
> It should depend only on the number of pixels/row and their color depth.
No. It can depends on alignment and other hardware restrictions.
> 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.
> Or does it have the whole screen width but starts at the upper left corner
> of the window?
No. However with other targets that might be. I might update the subtarget
to have something like that.
> what typecast do you mean?
See below:
> > If pixelpointer is
> > not (uint8 *) this will cause trouble. There is no need to typecast that
> > pointer. I'd use *pixelPointer=x<<(one of 0,8,16) for a 32 bit visual.
> 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. 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.
> Do I guess right that bits from 0 - 7 are used for blue, 8 - 15 for green,
> 16 - 23 for red?
Something like it. depends on endianness of the graphics board. The above
method automatically takes care of it.
> But then I don't understand the documentation where I read that all 3
> colors run from 0 - 65535, which would require a uint48 to store all those
> values.
That is only as long as you use the LibGGI internal color coding management
using MapColor and friends. Whenusing a directbuffer, you have a pretty much
direct "cut through" access path to the graphics hardware (as far as possible).
You then have to adapt to the hardware capabilities. It's the price to pay
for leaving out the intervening layers.
> I wanted to have a 256 x 255 window in X. I could have used 1024 x 768 too
> but that would have painted the whole screen. Still, this doesn't explain
> to me why only a quater of the 256 pixel width is drawn to.
Because you are accessing 32 bit wide data with 8 bit wide accesses. The
increments are too small.
> > Umm - that won't work even in palettized modes, as the only palettized
> > modes I know of are 8 bit wide, thus they only have entries 0-255.
> I want to have 3 x 256 colors, all pure red, green and blue colors
> in the color space of the visual.
> This should be doable by ggi or not?
Of course, when you are in a true color mode. But when in true color mode,
you need no palette.
Palette works like this: You only have 8 bit per pixel (old graphics cards
were low on RAM), but you don't want to be limited to only 256 fixed colors,
as in some pictures you need fine shades of red, in others blue, etc.
Now what they did is to add 768 bytes of extra RAM, that serve as a
lookup-table, the palette. They contain 256 entries with an RGB-triplet
each.
Now at every pixel, there is a table lookup, and when the pixel has say
value 0x23, it generates the color table[0x23], which might be r=0xff,
g=0xff,b=0x00 giving yellow.
In true color mode, this table is unused - the rgb values are generated
directly form the screen data.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
