Sign in to follow this  

Is SDL Efficient At All?

This topic is 4257 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
SDL is not noted for it's speed. However, for something like Zelda 3, it would do. If you are working with hand drawn pixel graphics and sprites, it's really nice. For speed, you should stick to a low bit depth, don't use alpha channels, and only draw when drawing needs to be done (no movment = no updates)

However, there is a lot that SDL *won't* do for you. Blending, scaling, rotation, and geometric primitives are *possible* in SDL, but use "the right tool for the right job". If you want these features, you should look into OpenGL for 2D graphics.

SDL is more than graphics though. It's also about input, windowing, image loading, etc. OpenGL is just graphics. It is possible to let SDL do all your event handling and whatnot but let OpenGL do the rendering. You can't mix SDL rendering with OpenGL rendering.

My advice is to use OpenGL. That's what i did and i never regretted it. OpenGL does SO MUCH MORE and it's lickity-split fast. It also uses your graphics card which is a huge plus. Of course, if you want to insure compatability for folks with no graphics cards, you might want to stick with SDL rendering.

I cut my teeth on this tutorial here:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=01
http://nehe.gamedev.net/data/lessons/linuxsdl/lesson01.tar.gz

The actual code there is geared towards linux, but i don't think there is anything linux-specific in it.

You might also check these out. They are probably more to the point:

http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/ogladv/index

Share this post


Link to post
Share on other sites
I've always been interested in this question: is rendering OpenGL graphics with SDL faster/slower/same as rendering OpenGL graphics with OS specific window handling code? Right now I use SDL+OpenGL, but if my speeds will be better, I'll remove SDL and place OS specific code in there.

Share this post


Link to post
Share on other sites
Quote:
Original post by NickGravelyn
I've always been interested in this question: is rendering OpenGL graphics with SDL faster/slower/same as rendering OpenGL graphics with OS specific window handling code? Right now I use SDL+OpenGL, but if my speeds will be better, I'll remove SDL and place OS specific code in there.


If it makes any difference at all (which I do not believe it will, you make exactly one call to SDL_GL_SwapBuffers() a frame, if that is your bottleneck then you're not doing enough to warrant a change =), is it really worth ripping your code to pieces over it?

If I told you that if you wrote your program in assembly it would go faster would you do it? Probably not, if you're smart. Is it worth putting in non-portable, more difficult to read( if you like SDL's API, I do anyway ) code just to do exactly the same thing? Only if you are getting a major fps boost.

Switching from SDL rendering to openGL makes sense as you can get 10 - 100 tiimes speed boost...

Share this post


Link to post
Share on other sites
I'd just like to mention that you guys are an awesome community. No where have I ever found so much good information and resources from such great people!

I'll have to look into the OGL rendering a bit more, this sounds like some great information.

Share this post


Link to post
Share on other sites
Quote:
Original post by KaptainKomunist
hxRender

The ease of SDL combined with the power of OpenGL.
The latest version has been stressed and tested. Raw blits are still faster with SDL, but as soon as you add scaling, blending, or rotation, this blows SDL away.


Exactly the kind of thing I'm looking for. This is great! I have renewed hope in SDL. Looking over it quickly, it's pretty much an OGL rendering wrapper for SDL?

Share this post


Link to post
Share on other sites
Quote:
Original post by chbrules
Quote:
Original post by KaptainKomunist
hxRender

The ease of SDL combined with the power of OpenGL.
The latest version has been stressed and tested. Raw blits are still faster with SDL, but as soon as you add scaling, blending, or rotation, this blows SDL away.


Exactly the kind of thing I'm looking for. This is great! I have renewed hope in SDL. Looking over it quickly, it's pretty much an OGL rendering wrapper for SDL?


It's a 2d graphics plotting wrapper for OpenGL.

According to the author, he's trying to distance hxRender from SDL but they still work great together.

Share this post


Link to post
Share on other sites
The fact remains.... using a 3d API for 2D rendering will be faster on modern machines than using SDL alone.

...

That said... SDL has it's uses and yours may be worth the time and effort put into SDL. If you don't use scaling, rotation and/or lots of primitives or blending, then SDL will, I repeat WILL work just as well as any 3d accelerated game out there. If you so choose to use lots( or any for that matter ) of scaling, rotation and/or blending then you WILL benefit from using a 3D API such as OpenGL or D3D.

Ok... that is out of the way.... modern and movning on... current video cards will not support 2D hardware acceleration etc. This has been made blatantly apparent by the dropping of DirectDraw (our last hope at a 2D accelerated API) from DirectX 8. I hope you will all realize that scream, cry, bawl, whine all you want... 2D as an API is dead.... Even GDI has gone the way of the dinosaur. When it comes to serious games.... 2D is best done emulated from 3D.

Don't fret though... think of this as using a nuclear bomb to fix a small uprising in San Fransisco where illegal aliens are protesting the incarceration of people helping illegal aliens as opposed to you and I just agreeing to pay more for our American made products...

Okay, bad example... most people will pay less because they don't understand the consequences of their actions... Pay the extra 2-3 months to learn the 3D API and live better because of it.

Now, if only we could get a 2D - 3D conversion web page.... many of us would be greatful even if we know how to do it. It doesn't make it any easier now does it.

Thank you all for your great contributions to Gamedeve.net. I can't describe how much these forums have increased my knowledge of programming.

Thanks again
-- Drunken McDrunken-ButterPants

Share this post


Link to post
Share on other sites
IMHO I think people just need to get away from "2D" and "3D" API's when you're discussing OpenGL or Direct3D.

Direct3D and OpenGL are *graphics* API's. End of discussion. If you want to give your scene a "3D" appearance, then you take advantage of the depth buffer and z-plane. If you don't, you don't.

However, I would classify API's such as DirectDraw, SDL (vanilla) and PopCap as 2D just because they are based on DirectDraw on some level of their implementation.

But to get back to the OP, I've only ever used SDL+OpenGL. For me it's just as fast as using a win32 implementation instead of SDL to handle window management and the message queue. *shrug*

hth,

Share this post


Link to post
Share on other sites
wasn't the Linux mod of Quake 4 made using SDL, just what I heard, so if this is true, I believe SDL can be efficient in higher end problems ;p

... just sayin

-Karakadin

edit: errr, port, not mod, sorry

Share this post


Link to post
Share on other sites
Quote:
Original post by Karakadin
wasn't the Linux mod of Quake 4 made using SDL, just what I heard, so if this is true, I believe SDL can be efficient in higher end problems ;p


I believe you're correct @Karakdin. Also the last time I played America's Army, I did notice the SDL.dll kicking around. I presume this is for the Linux port as well, but I never tried editing any of the .ini files to find out..:)

Bottom line is that SDL+Graphics API is more than capable.

Share this post


Link to post
Share on other sites
Both the above games will have used SDL for cross platform (or probably linux specific in thier case) window handling and possibly input mapping. They will have used SDL to create the above, then handd everything else off to OpenGL, so technically, not using SDL in the sense the OP has been doing.

Spree

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
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.


Blending (transparent bitmaps) is done in software in SDL. The bigger the blend, the slower it gets. If you want faster blend times, use OpenGL as others have already said.

Quote:
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?


Well, considering Zelda III ran at something like 256x256 resolution, I think it's completely possible to do that in SDL. ;)

Share this post


Link to post
Share on other sites

This topic is 4257 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this