Hi !
> I have a Matrox Milenium, there are no restrictions with this card
> acording to align and noacces.
This is usually not a card restriction, but rather a CPU/Bus restriction.
> My test application should simply draw a red, green and blue color run
> above each other. The color run should start at black left and end at full
> color on the right side of the window.
I'll comment on that below.
> My application only runs when uint8 or uint32 is chosen for *pixelPointer.
>
> Using uint16 results in a segmentation fault when there is written to the
> direct buffer. The same is true when I alter the slimy.c file to use
> uint16 instead of uint8.
This is very probably caused by overrunning the buffer. See below as well.
> Colors are only grayscale when run with uint8 though the card should
> support truecolor, X at least uses it. But this is probably because uint8
> is used that means 256 colors available.
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.
> All versions get a segmentation fault when ggiClose is called under the X
> target.
> If run under kgicon there is no seg. fault; same situation with slimy.c .
Yeah - the kgicon target maps the whole buffer thus allowing for overruns.
> #include <stdlib.h>
> #include <stdio.h>
> #include <ggi/ggi.h>
>
> const ggi_directbuffer *directBuffer;
> ggi_visual_t visual;
>
> void fail( char *reason )
> {
> fprintf( stderr, "%s", reason );
> if ( visual != NULL )
> {
> ggiClose( visual );
> ggiExit();
> }
ggiPanic(); might be useful here ...
> void setGraphics( void );
How does that look like ?
> int main( int argc, char *argv[] )
> {
> uint16 x, y, stride;
Don't do that without need. It slows down modern CPUs. Use int.
> ggi_mode mode;
> ggi_pixel pixelValue; // *pixelPointer;
> ggi_color colour;
> uint8 *pixelPointer;
>
> visual = NULL;
Not needed. ggiOpen will set it, no matter what.
> setGraphics();
> if ( ggiResourceAcquire( directBuffer->resource, GGI_ACTYPE_WRITE ) != 0 )
> {
> fail( "Error acquiring DirectBuffer\n" );
> }
> pixelPointer = directBuffer->write;
>
> 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.
Moreover - What should stride-mode.virt.x be ?
I'd understand pixelPointer += stride/sizeof(*pixelpointer) - 256; as there
were already 256 increments on pixelPointer.
As well take care about the typecast 2 lines before. 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.
> void setGraphics( void )
Ah - o.k. answers my question above.
> {
> int x,y;
> int i;
> ggi_color colour;
> ggi_mode *mode = (ggi_mode *)malloc( sizeof( ggi_mode ) );
>
> mode->frames = 1;
> 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".
> mode->virt.x = mode->visible.x;
> mode->virt.y = mode->visible.y;
> mode->size.x = mode->size.y = 0;
> mode->graphtype = GT_32BIT;
> mode->dpp.x = mode->dpp.y = 1;
>
> ggiSetFlags( visual, GGIFLAG_ASYNC );
>
> ggiCheckMode( visual, mode );
>
> ggiSetMode( visual, mode );
Umm - you might want to check for errors here ...
> for( i = 0; i < 256; i++ )
> {
> colour.r = i;
> colour.g = 0;
> colour.b = 0;
> ggiSetPalette( visual, i, 1, &colour );
> }
Setting a Palette is ignored when not in a palletized mode. Look at the
demos on how to check for one.
> for( i = 0; i < 256; i++ )
> {
> colour.r = 0;
> colour.g = i;
> colour.b = 0;
> ggiSetPalette( visual, i + 256, 1, &colour );
> }
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.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
