[SDL] sensible optimization [was re: tile based _junk_]

Frank J Ramsay fjr at epsilon.com
Fri Aug 20 10:47:35 PDT 1999

Darrell Johnson wrote:
> > btw, the groundlayer->buffer move is:
> >
> >  memcpy(backBuffer,groundBuffer,_bufferSize);
> Wouldn't it more typically be two of these, adding up to the
> groundbuffer size? (don't get me wrong, there wouldn't be any
> significant performance difference, the setup overhead is light, I'm
> just nitpicking)  Or do you not let the groundbuffer get split?

I don't split the ground buffer, and I update it when needed.  When it is
updated I set a flag telling the system to foget the dirty rectangles and
do a full window refresh (refering to the refresh buffer->physical display)
Yes, this is slow for animated tiles, but I would use palette rotation to 
solve that.

> Certainly not faster, but nearly as fast (the difference being cache
> misses from switching from one tile to another).  Where the full
> regeneration could be faster is that you can combine the sprite drawing
> step with it.  I'm assuming the backbuffer is a system RAM
> double-buffer, which is then blitted into the video ram during the
> retrace. If you're not writing a bit here and a bit there, you can
> efficiently write to a true page-flipper and drop the double-buffer blit
> (if it's available, which it should usually be).
Yes, the buffer is in system RAM and I write the buffer to the SDL_Surface 
then call the updaterec(? sorry don't have the docs in front of me) function 
(which I believe waits for the next refresh to update the display)

> The really great thing about a linear memory access renderer is that in
> many cases you'll be fast enough to do your rendering directly onto the
> front buffer during the retrace(heresy! another case where fast
> computers change the rules); of course, you have to test to be sure,
> unless you want flickering.  After all, if there's more than enough
> bandwidth to do a back-buffer blit to the screen each retrace and CPU
> cycles to spare, why not render on the fly?
> A custom linear renderer is especially beneficial for non-square tiles.
> Remember that writing one or two bytes is as slow as writing four
> word-aligned bytes (on a 32 bit computer), so if you aren't writing
> pixels in aligned words, you're slowing your writes down to a half or
> quarter speed.

Ok, now were getting down to the important things, how to render your image
(to the buffer) fastest.  I'll admit I'm not familure (at least not by the
name you use) with Linear rendering. So I really can't comment on the
relitive merits it.  But I am curious how it would deal with almost every
scaline of every tile having transparency information.


Frank J. Ramsay, Software Engineer - Epsilon Data Management
fjr at epsilon.com
framsay at epsilon.com

Genetic Engineering: (noun) Proactive Evolution.

More information about the SDL mailing list