Compiled sprites stopped being a good idea quite a few years ago,
probably before the 486. They increase memory bandwidth a great deal,
while simple blitting is memory bound already, even if you pump
nothing but graphics data.
RLE encoding is faster, more flexible, handles clipping relatively
well - and it’s built into SDL.
[If you think 640x480 at ~20 fps is a good frame rate, you might want
to stop reading here.]
Besides, modern computers aren’t built for software rendering, so all
this is pretty much moot anyway. Accessing the VRAM is insanely slow,
even compared to accessing cold system memory. It’s not always
possible to blit from system memory to VRAM using DMA, and even when
it is, that’s also relatively slow.
Video cards are designed for hardware accelerated blitting, and that’s
the only way you can get decent performance (*), at least in
resolutions higher than 320x240. For now, your best bets are probably
glSDL:
http://olofson.net/mixed.html
…or using OpenGL directly. The latter obviously means that your game
won’t run without a 3D card and OpenGL drivers. (Well, it might
"run", but software OpenGL is insanely slow.) Direct3D/DirectGraphics
will do the job as well, but then portability goes down the drain, of
course, and it has the same system requirements issue as using OpenGL
directly.
Then again, if your game is just too heavy to run with software
rendering, that’s no issue at all, especially since the computers
that are most likely not to have 3D acceleration also have the
weakest CPUs. So, if acceleration is required for speed, just use
OpenGL or Direct3D directly. You can make much better use of the
video card that way.
(*) Note that my definition of “decent performance” is rather
extreme. IMHO, anything below retrace sync’ed full frame
rate is a compromise. Now that pretty much every computer
has 3D acceleration, I’m starting to consider anything
without sub-pixel accurate rendering a compromise as well.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 08 April 2003 14.39, Andre de Leiradella wrote:
Hi All,
I’m thinking about writing a library to compile images to machine
code to fast-blit them over a surface. I know the compiled sprites
will only work on surfaces with the same pixel format they were
compiled for.
Should I expect a application using compiled sprites with SDL to be
faster than using SDL_BlitSurface? Can I count on the pixel format
of a surface not to change when SDL_MUSTLOCK evaluates to 0? If
it evaluates to something else, in which situations can I expect
the pixel format of the surface to change, toggling from windowed
mode to fullscreen and vice-versa maybe?