[…]
Moving Sprites With SDL
it seems straightforward, however that program re-draws the entire screen
every frame.
The reason for doing it that way is that it’s simple, handles all sorts of
situations, including full-screen scrolling, and tends to run fast enough on
most platforms (that is, those with hardware acceleration) without relying on
or suffering from API, driver or hardware quirks.
[…]
blit the screen rectangle (same x,y,size as sprite) into a temp. buffer,
blit the sprite to the screen,
update/flip,
blit the screen temp. buffer back to the screen
This is indeed how many games did “software sprites” on 8 and 16 bit systems;
IIRC STOS did something very much like this on the Atari ST, although I think
it used a third full-screen buffer for the sprite “backsave.”
The problem with this approach these days is that basically any modern
graphics system makes it EXTREMELY expensive to read from the frame buffer.
(Sometimes slower than reading from the hard disk. Not kidding!) Modern PCs
(and most other devices) just aren’t designed for software rendering, and
reads from VRAM are particularly problematic. Also, hardware accelerated
rendering adds the need for synchronization, making this even slower.
The proper way is to always render in the “forward” direction. What you can do
in a case like this is to remove the sprites by restoring the affected parts
of the background directly from the source; ie tiled map, background image or
whatever you’re using.
If rendering the background is too complex and/or expensive to do like that,
render the full background into an off-screen surface first, and keep that
surface around for sprite removal.
Of course, you should SDL_DisplayFormat() the source graphics for maximum
speed - but actually, I think even SDL converting pixels on the fly (say, if
you have custom software rendering code that supports only 32 bit RGBA) is
going to be a lot faster than anything involving reading from the frame
buffer.
Oh, BTW, I once wrote an example, Fixed Rate Pig (playable minigame), that
demonstrates this, among other things. Apart from only updating the areas
around the sprites, it also has a simple “smart refresh” engine that avoids
restoring the same area over and over if multiple sprites hang around in the
same general area.
IIRC, it keeps track of doublebuffering as well (one set of “dirty rectangles”
for each buffer), so it should work on an actual double buffered display as
well.
http://olofson.net/mixed.htmlOn Wednesday 18 April 2012, at 16.18.33, Gordon Henderson <gordon+sdl at drogon.net> wrote:
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
‘---------------------------------------------------------------------’