Hallo!

> This is usually not a card restriction, but rather a CPU/Bus restriction.

Ah.

> This is very probably caused by overrunning the buffer. See below as well.

What causes the overrun? The wrong usigned typ? What type should
directBuffer be if I want to have truecolor?
 
> 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.
 
> 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?
 
> >   if ( visual != NULL )
> >     {
> >       ggiClose( visual );
> >       ggiExit();
> >     }
> 
> ggiPanic(); might be useful here ...

Ok.

> > int main( int argc, char *argv[] )
> > {
> >   uint16 x, y, stride;
> 
> Don't do that without need. It slows down modern CPUs. Use int.

I took it from slimy.c I think, or some other demo, can't remember.

> Not needed. ggiOpen will set it, no matter what.

Ok.
 
> >   stride = directBuffer->buffer.plb.stride;
> > 
> >   for ( y = 0; y < 85; y++ )
> >     {
> >       for ( x = 0; x < 256; x++ )
> >     {
> >       //colour.r = x;
> >       //colour.g = 0;
> >       //colour.b = 0;
> >       //pixelValue = ggiMapColor( visual, &colour );
> > 
> >       *(uint8 *)pixelPointer++ = x;
> >     }
> >       pixelPointer += stride - mode.virt.x;
> 
> Be careful, if pixelPointer is not a uint8. Note, that stride is always given
> in bytes, which must be compensated, if larger datatypes are in use.

How should this be done for true color?

stride = directBuffer->buffer.plb.stride / sizeof( uint32 );

Right?

> Moreover - What should stride-mode.virt.x be ?

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)? Obviously I don't
know the window position, that's why I guess on the X Target the frame
buffer is restricted to the window. But what size does stride then have?
stride represents the size of one row of the screen in bytes, right? It
should depend only on the number of pixels/row and their color depth.
But if used with the X target stride would have the number of pixel *
colordepth of only the window. Is that correct?
Or does it have the whole screen width but starts at the upper left corner
of the window?

> I'd understand pixelPointer += stride/sizeof(*pixelpointer) - 256;

Ah, guess this explains my question from above.

> as there
> were already 256 increments on pixelPointer.

right.
 
> As well take care about the typecast 2 lines before.

what typecast do you mean?

> 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?

Do I guess right that bits from 0 - 7 are used for blue, 8 - 15 for green,
16 - 23 for red?
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.


> >   mode->visible.x = 256;
> >   mode->visible.y = 255;
> 
> This is quite an oddball resolution. I wonder if it works anywhere but in x
> or other "metatargets".

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.

> >   ggiSetMode( visual, mode );
> 
> Umm - you might want to check for errors here ...

yep, just want to get it run.
 
> Setting a Palette is ignored when not in a palletized mode. Look at the
> demos on how to check for one.
> 
> 
> 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?
 
gr. matthias

Reply via email to