SDL and SFML

[Austin J]

I understand that these two are based a lot on preference. SDL is lower level and made for C. SFML is based for C++. One thing I keep hearing a lot is that SFML is much faster than SDL. I've seen the benchmarks on the SFML site, but well, always better to go to more than one source, especially a non-biased one. For those of you who have worked with both, which tends to have better performance?

[Disch]

I haven't used SDL 2.0 (or "SDL HG" as it's referred to on the main SDL page), but I hear it's solved all the big problems with SDL 1.2.

You definitely should not bother with SDL 1.2. At all. It's very old and employs extremely outdated drawing concepts like blitting and dirty rects -- many of which are unsupported by modern video hardware (we're talking like 10+ years out of date -- this stuff is ANCIENT). Which is why SFML is said to perform better.

The only way to get any kind of reasonable performance out of SDL 1.2 is to bypass SDL's rendering entirely and do your rendering directly with OpenGL -- but if you're doing that, SDL becomes little more than a window manager and something like Glu works just as well or better.

Either version of SFML (1.6 or 2.0) is definitely better than SDL 1.2 for that reason.


As for SFML 2.0 vs SDL 2.0.... I couldn't say which is better, but I tend to have a personal preference for SFML.


EDIT:

One thing I really like about SFML is that it seamlessly integrates with both Qt and wxWidgets (crossplatform GUI libs). SDL 1.2 only allowed you to have 1 window open and it demanded control over it, so trying to get it to work with GUI libs was a real challenge.

I don't know whether or not SDL 2.0 addresses this or not. It wouldn't surprise me if it did.. and it wouldn't surprise me if it didn't.

[Austin J]

What about when I want to use openGL? SFML can work with it but I don't know how well, I haven't heard much about it.

[Disch]

SFML is designed so you can switch between SFML rendering and OpenGL rendering. And in fact, SFML's Texture class is an OpenGL texture, so you can still load images into OpenGL textures as easily as you would with normal SFML.

Switching between the two is a simple function call:

// do OpenGL drawing here

window.pushGLStates();

// do SFML drawing here

window.popGLStates();

// do more OpenGL drawing here 

EDIT:

As for textures...

// no need to call glGenTextures/glTexImage2D/glDeleteTextures .. just load
//   an SFML texture:

sf::Texture texture;
texture.loadFromFile( ... );

// and instead of glBindTexture...

texture.bind();

// ... polygons draw in OpenGL will now be textured with that texture 

[Bourgond Aries]

I know SFML-2.0 quite well (Don't go 1.6, it's a few years old, 2.0 is very stable and has loads of nice features), and I must say, it's far better than what I tried to do with SDL.

The benchmarks are actually a bit one-sided, because they were done on pure SDL I think, which uses CPU rendering instead of the GPU. However, when equally matched (both use GPU rendering), SFML is still faster.

Not only that, but SFML is OO, which is really comfy.

One annoying thing that I fixed in SFML is that it isn't really made for passing window control to different threads. The OpenGL rendering contexts are not deleted, which results in a memory leak. They're not deleted because SFML can't know when a thread dies according to Laurent Gomilla.

http://en.sfml-dev.org/forums/index.php?topic=10309.0

SFML-2.0 works perfectly with OpenGL, if you want you can use SFML as a window manager, sound manager, and directly call openGL commands. In fact, SFML includes an OpenGL.hpp (located in SFML/OpenGL.hpp), which is a correct version you can include. It works very well, once made a little 3D area where I moved around.