Re: Linux games programming tutorial-part2

[Alexandre Courbot <alexandre.courbot@accesinternet.com>]

Christian Reiniger wrote:

> > /* Initialise */
> >   if (vga_init()!=0) {printf("Error initialising svgalib!\n");_exit(1);}
>
> IIRC exit () (without the leading underscore) is the standard C function
> for abnormal exit.

Right. I will use this instead.
 

> >   getchar();
> 
> wouldnīt getch () be better?

Why would it be? getchar read from stdin, that sufficient. No?

> > This function read the pcx image from file to target, assuming the image is size bytes lenght:
> >
> > void readpcximage(FILE * file,void * target,int size)
> > {
> >   unsigned char buf;
> >   unsigned int counter;
> >   int i=0;
> >   while(i<=size)           /* Image not entirely read? */
> >     {
> >       fread(&buf,1,1,file);      /* Get one byte */
> 
> You should add a comment here that fread()ing single bytes can be quite
> slow. For demonstration purposes itīs ok, but for real-world code
> reading larger chunks at once (e.g. 8k-blocks) is better.

Right too.

> >       if ((buf&192)==192)        /* Check the 2 most significant bits */
> >         {                        /* We have 11xxxxxx */
> >           counter=(buf&63);      /* Number of times to repeat next byte */
> >           fread(&buf,1,1,file);  /* Get next byte */
> >           for(;counter>0;counter--)   /* and copy it counter times */
> >             {
> >               memcpy((target+i),&buf,1);
> 
> memcpy () is way too much overhead for copying just one single char.
> target [i] = buf;   would be better.
> 

Yes, but the reason I use this is that the pointer is void typed. So I
can't
use target[i], excepted by forcing the type ( (char*)target[i]=buf). But
it is possible and should be better here, I'll fix it and add a comment.

> >   target=(void *)malloc((*lenght)*(*height));
> > Now it is usuable. We do the memory allocation when we know the size of the sprite, in order to don't waste memory. After the allocation we can safely load the sprite and display it.
> 
> Some note that usually the bytes per pixel has to be included in the
> size calculation would be good here.

bytes per pixel will be introduced in the next part, with 16bpp and
24bpp modes (yum yum multi depth programs! :) )


> > See you on next part!
> 
> Iīm looking forward to it :)
> 

Thank you!
Alex.