[SDL] comparing cpu usage

[Neil Bradley]

> Are mostly functions that call putpixel() to draw a pixel onto a
> software surface. erase_particles(), draw_particles() for example, both
> call putpixel. Would it be best to integrate the putpixel code for all
> the varying bit depths straight into functions that use it?

Depending upon the code, absolutely. Eliminate run time comparisons on a
per pixel basis. That's a lot of pixels! You also might try doing an
inlining of those functions if your compiler supports it.

Pixel access is PAINFULLY slow. It might be tempting to do something like
this to draw a blue box:

for (y = 0; y < 200; y++)
{
    for (x = 0; x < 200; x++)
    {
       putpixel(x, y, 0x1f);
    }
}

To draw a blue box, but that's HORRIBLY slow. Go look at the putpixel
function in SDL. It's big, and general purpose, bit it 'aint fast.
Instead, get a pointer to the surface, and do something like this
(assuming 16bpp):

pu16SurfacePtr = &((UINT16 *) surface->pixels)[startx + (starty *
                 (surface->pitch / sizeof(UINT16))];
u32PointerAdvance = ((surface->pitch / sizeof(UINT16)) - xcount;

for (y = 0; y < ycount; y++)
{
   for (x = 0; x < xcount; x++)
   {
       *pu16SurfacePtr++ = 0x1e;
   }

   pu16SurfacePtr += u32PointerAdvance;
}

In short, it's better to get a pointer to the starting location of the
surface and scribble on it directly. *NEVER* Use putpixel() to write large
amounts of data to a surface.

Of course the above routine is designed for 16bpp. You'll have to make one
for 32bpp and one for 8bpp if your game supports it.

> Is that a
> major slowdown? I remember reading that putpixel() is extremely slow,
> even to software surfaces.

Yes it is, considering that you're doing a multiply, an add, and an offset
for every single pixel you write.

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            In the land of the blind, the one eyed man is not
Synthcom Systems, Inc.  king - he's a prisoner.
ICQ #29402898