SDL vs SFML

closed account (1yvXoG1T)
So I just recently dove head first in to the art of SDL. More than anything, my reason for choosing this one is that I know it is widely used and has been tried and true for working with any kind of graphic setting.

But I recently started reading just a little bit about SFML and it essentially seems to show itself as SDL but faster.

Which do you prefer and why?
I prefer SFML.

SFML abstracts a lot better than SDL.

SFML has built-in support for printing text, streaming/looping music, playing sound effects, whereas SDL only provides the bare bones minimum (although there are add-on libs to help with the rest)

SFML works on top of OpenGL, which is fast and hardware accelerated. SDL works on top of ancient 2D surface blitting techniques that haven't really been hardware accelerated in years. The whole idea of blitting is rather antiquated nowadays.

On top of being faster, 3D rendering offers other perks, like alpha blending, rotation, color tinting, etc.

SFML is still in active development. SDL has been stuck at v1.2 since I used it last, which was like 5 years ago. They've been saying that a 2.0 is in the works, but it's been in the works forever.
They've been saying that a 2.0 is in the works
1.3, not 2.0.

SDL has a few quirks. SDL_BlitSurface() does what it feels like with alpha across platforms; its synchronization objects are horridly slow on Windows, for some reason; some of its sister libraries, SDL_ttf in particular, are a trainwreck. It got to the point where all the responsibility related to graphics I left to SDL was allocating and refreshing the screen. Everything, from surface allocation to drawing to the screen, was handled by my code.
But, it does have a few points in its favor:
* Building a fully static executable without any external dependencies under Windows is very easy.
* Since it's been around for quite some time, it's supported everywhere (I've seen SDL-based code ported to the PSP and iPod) and there are many tutorials written for it. Google ffmpeg sdl.
* If you want to write straight OpenGL, it eliminates much of the tedium of dealing with window management, screen allocation, etc.
I don't know how SFML does in any of these.
1. I haven't been on Windows for quite some time, so I can't really confirm nor disapprove SFML creating external files for that.
2. SFML is also widely supported, but again, I don't know about PSP and iPod ports. There are many tutorials for it, too. But a lot less than for SDL, since it's a lot more self-explanatory.
3. Window management and the like can be done with SFML.
Last edited on
closed account (1yvXoG1T)
Well, perhaps I should pack up my SDL bags and head for SFML. It sounds like the only possible advantage that SDL has over SFML is multi-hardware porting but being that I'm only developing for Windows (for now) that wouldn't prove to be too much of a problem.
Multi-platform isn't that much of a problem, considering you use systems like Windows, *nix, FreeBSD and the like. I just stated that I don't know whether PSP/iPod porting is supported.
closed account (1yvXoG1T)
My final two cents on this: I've worked through all of the basics for both SDL and SFML (hence, my absence from the boards for the past 6ish days) and personally, I actually found SFML to be better than SDL, in my opinion. I appreciate the input from everyone :D (Finished my first game using a graphics library (Pong) w00t!)
Well, SDL has faster 2D animation and graphics for high-speed action games than SFML does, at least on common hardware such as a Windows-based PC with an Intel graphics card like mine. Therefore, for me it is SDL until I get into DirectX. The proposed SDL 1.3 is supposed to have a DirectX/OpenGL backend; we'll see if it ever happens.
Well, SDL has faster 2D animation and graphics for high-speed action games than SFML does, at least on common hardware such as a Windows-based PC with an Intel graphics card like mine


Ummm... what?

SFML uses OpenGL under the hood, which does everything in hardware. It doesn't get any faster than that.

SDL uses ancient blitting techniques that would only be supported as legacy in any card made in the last 8-10 years (if supported at all). On machines where blitting isn't hardware accelerated, it's all done in software
Topic archived. No new replies allowed.