Hi everyone!
On a forum I’ve seen that SDL is quite slow for simple tasks, it’s even
slower than OpenGL most of the time.
On 2D games with a lot of sprites and details it really is slooow.
Why?
Does SDL only use CPU (software)? Doesn’t it also use GPU (hardware)?
Thank you for answering.
Kurapix
On 2D games with a lot of sprites and details it really is slooow.
Why?
Does SDL only use CPU (software)? Doesn’t it also use GPU (hardware)?
Thank you for answering.
In many cases, yes. It’ll use hardware when used with OpenGL, obviously,
and on some platforms, if you’re careful to put everything into hardware
surfaces, it’ll use them.
Most “slowdown” comes from blitting between different surface formats,
so SDL has to convert on the fly. Preconvert and most of the slowdown
resolves itself.
(And naturally, blitting less is faster, and using OpenGL is probably a
better idea at this point, even for 2D stuff.)
–ryan.
Ok.
So if I want my 2D game to go fast, I need to use OpenGL hardware surface?
It sound quite a heavy solution.
To rewrite a full SDL only game to an OpenGL-SDL it takes a lot of rewrite
no?
Or can the SDL handle OpenGL hardware surface by itself?
Why doesn’t SDL have hardware acceleration implemented in itself? (I haven’t
seen this question in the FAQS).
It would be great since on some platform, SDL is port but not OpenGL (so if
there isn’t OpenGL … no hardware acceleration).
I’ve always though of OpenGL for 3D and SDL for 2D …
Thank you for answering.
Kurapix
2007/6/2, Ryan C. Gordon :>
On 2D games with a lot of sprites and details it really is slooow.
Why?
Does SDL only use CPU (software)? Doesn’t it also use GPU (hardware)?
Thank you for answering.In many cases, yes. It’ll use hardware when used with OpenGL, obviously,
and on some platforms, if you’re careful to put everything into hardware
surfaces, it’ll use them.Most “slowdown” comes from blitting between different surface formats,
so SDL has to convert on the fly. Preconvert and most of the slowdown
resolves itself.(And naturally, blitting less is faster, and using OpenGL is probably a
better idea at this point, even for 2D stuff.)–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
So if I want my 2D game to go fast, I need to use OpenGL hardware surface?
It sound quite a heavy solution.
To rewrite a full SDL only game to an OpenGL-SDL it takes a lot of
rewrite no?
Depends on the game. In most cases, the 2D path is fast enough, though,
and some small optimizations can handle any problems you’re currently
having.
Why doesn’t SDL have hardware acceleration implemented in itself? (I
haven’t seen this question in the FAQS).
It does, but most video targets don’t support it. You can get hardware
surfaces from, say, DirectX, and as long as everything is in a hardware
surface, you can blit between them with hardware acceleration.
It would be great since on some platform, SDL is port but not OpenGL (so
if there isn’t OpenGL … no hardware acceleration).I’ve always though of OpenGL for 3D and SDL for 2D …
Increasingly, OpenGL and Direct3D are going to be the best way for 2D,
too. The “hardware accelerated” 2D interfaces don’t exist in most
targets (including Mac OS X and Linux), and on Windows, DirectDraw has
been deprecated for literally years now. Apple and Microsoft both
recommend you use the 3D interfaces, even for 2D work, if you can.
In SDL 1.3, we can use Direct3D or OpenGL behind the scenes with the
current 2D SDL APIs (and fall back to a software renderer when we
can’t). In 1.2 there’s a patch floating around called “glSDL” if you
want to experiment.
But again, for most 2D software, you can still make it usable. Usually
you just have to make sure you preconvert your surfaces, and one or two
other minor things, to remove most reasonable bottlenecks.
–ryan.
I have ported many SDL things to ‘slower’ systems, and the ammount of
bloatware
programming style sometimes is hurrendous, even a supposed port or remake of a
zx spectrum game end up a big pile of steaming blits.
If you want to keep SDL fast as ryan says keep all the surfaces the
same format,
and crucially think about what on the screen actually needs to be re-drawn, if
you dont have to redraw the whole screen with SDL_Flip( then dont be
lazy, only
redraw the screen where and when it is neccesary. This can be complicated to
implement but the speed increases are worth it, especially if you want to run
your program on older or less powerful systems.
Dont rely on gzimmerwhammer GFX card systems to hide lazy programming!