Is SDL Efficient At All?

Started by
23 comments, last by GameDev.net 17 years, 11 months ago
Working with SDL I found out how much of the CPU it utilizes with simple resolutions like 1024x768, let alone higher. Things slow down a lot and I have a 3500+ AMD64, 6600GT nVidia GeForce, 2GB of pc3200, Win XP Pro. I made a test where a tiled map would be rendered in a loop, and I made a console-window-like bitmap scroll down semi-transparently when the tilda was pressed. Well it was running fine until I made the window come down. The more that came onto the screen, the slower the entire application went until it was pretty much 1fps or less. How could, something simple as a transparent bitmap across half the screen slow it down that much? I was only running 800x600, and it was running fine when the I didn't make the console window come down. This and other things leads me to my point. Is SDL even that efficient at running many objects on the screen at once? I want to have a multitude of transparent and key transparent objects on the screen at once moving around as the player scrolls the screen around. My example would be something like Zelda III for SNES. Is something that complex possible to do smoothly with SDL? If it's not, I've been looking to take a stab at allegro, as it's a similar raster-based blitting API for 2D graphics. Some good information on this subject would help me out quite a bit! Thank you everyone.
-Conrad
Advertisement
SDL can still be used for simple games and stuff.

To use effectively:
*No alpha blending
*Try not to use high resolutions
*Stick to 16 bit color maximum
*Use colorkeying instead of alpha channel

I recommend SDL to these groups:
*Beginners
*Making retro games
*Making emulators
*Making linux games
*Software Rendering

SDL does not use the power of today's graphics cards. Basically the CPU is the prime indicator of how fast it will run, and depending on the application, an older graphics card might handle the direct draw pixel manipulation better.
You might want to use OpenGL with an SDL-created window. SDL will be considerably slower than OpenGL for rendering, but it is easy to use them together. If speed is an issue, I'd do this.

As for an SDL do that by itself, well, that's a little iffy. In general, you don't want to get above 800x600 with SDL on software rendering(non-OpenGL, though SDL does have minor support for hard-ware accelerated graphics without OpenGL). However, on a considerably slower machine(Pentium 4 2.5ghz, 512gb RAM, geforce 2 mx), I was able to make smooth-running games at 640x480 with 20+ sprites(32x32) with key-transparency running at 50+ fps.
Was one a memory bitmap and one a video bitmap? Were they using different pixel formats? I'm pretty sure you should be getting more than 1fps.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other player's eyes with his King.
Quote:Original post by smart_idiot
Was one a memory bitmap and one a video bitmap? Were they using different pixel formats? I'm pretty sure you should be getting more than 1fps.


To tell you the truth I don't know how I'd tell the difference. I load 32-bit bitmaps into memory using the SDL_Surface* type from file and just blit them. I'm not the biggest SDL buff, but I know enough to get things going.

I'm interested in creating an SDL app through OpenGL though. That way the video memory would be used and the GPU utilized for rendering? That would increase the performance by buttloads. :)

There wouldn't happen to be any tutorials or information readily availible for such a task would there?
-Conrad
I think Google will turn up some SDL with OpenGL links. Basically you just initialise SDL with the appropriate flag and then do all your rendering in OpenGL.

Also look up SDL_DisplayFormat. You should be using that on all your surfaces except the screen. But even with that, you can't really do alpha blending. That requires OpenGL or DirectX.
If you want power with SDL use OpenGL's rendering.

I got 500 FPS with OpenGL's rendering when doing the same thing in SDL's rendering got me 20 FPS.

Learn to make games with my SDL 2 Tutorials

Okay, we need to bring out some benchmark programs.
If you're using alpha blending with the DirectDraw backend, then yes, it be horribly slow, because the video surface is in VRAM and has to be read multiple times. Use a software surface, or the GDI backend.

Before you say that using software surfaces defeats the point: there is no way to get fast alpha blending with hardware surfaces because most cards don't provide 2D acceleration anymore, at least not for things like alpha blending.

Hope this helps.
SDL does what you tell it to do as fast as it can.

Here is an example of how changing what you are doing but not whats drawn can give large speed boosts.

Try ensure all you images are in the same RAM ( all in video ram, or all in main ram ). If you are using Alpha blending go for software too.

We all know that opengl / directx will trouce SDL, so there is really not a lot of point making comparisons with it. It comes down to doing what you can to get smooth framerates in the region you are comfortable viewing ( 60 is a good choice ). In some cases, if you are smart about how you set up all your blits, you can achieve these kind of framerates even at high resolution.

This topic is closed to new replies.

Advertisement