Is SFML a better choice over SDL?

In the general case there isn't a "better" choice -- they're both very good, very popular APIs which are under active development, and they have very similar capabilities. You really need to make your own choice between the two based on your own preferences, but if you're unable to decide then you won't be disadvantaged either way by simply picking at random. If you really want to make an informed decision my suggestion would be to have a look at the tutorials and documentation available for both, download and set-up both and attempt some relatively simple task such as opening a window to display a single graphic, and then choosing whichever you personally feel more comfortable with.


Some notes, in no particular order:

• SDL is more of a C-based API (but is still easily and very commonly used with C++), while SFML is more C++ oriented with an object oriented structure. SFML does provide a less commonly used C version.
  
• SDL is older, but both APIs have impressive-looking new versions under active development, and you can use these versions now if you wish to do so -- in the case of SFML I'd say using the newer version is even recommended.
  
• Due to it's maturity there are more tutorials and example code around for SDL, although obviously less so for the under-development 2.0 version which has some differences. However, this is somewhat balanced by what I personally think is higher quality official documentation for SFML.
  
• Unless you use the newer version or are doing your own rendering with OpenGL or Direct3d, the drawing functions provided by SDL are not hardware accelerated, while SFML is. The new version of SDL fixes this however.
  
  
  You could also consider Allegro.
  
  Hope that's helpful!

Hmm so other than ease of use and general support for them on line with tutorials why do people swear by one or the other with performance etc? Is it a placebo effect?

SFML graphics are hardware accelerated by default; SDL runs on the CPU by default but can be hardware accelerated when you want it to be (because SDL can run on systems that don't have a GPU).

A naive user might say, "Look, my 'hello world' SDL program is slower than my 'hello world' SFML program, thus SFML must be faster than SDL!", not realizing or researching or caring to find out why one happened to be faster than the other, in what circumstances, for what reasons, with what settings, on what hardware, running what operating system. Then they go off and tell other users, "SFML is faster than SDL" or "DirectX is faster than OpenGL" or "Mac OSX is faster than Windows 7".

Why do people swear to it? 95% of the time, it's probably a lack of understanding.
The other 5% of the time, you have someone who actually understands it - but it's hard to know when that's actually the case or not, because the first situation occurs more often.

That said, I've used both of them, and like both of them, and can program in either of them. I'd recommend SFML over SDL, but both are good choices.
SFML pros:

1. I like SFML's documentation better - mostly this is just the web interface to the documentation being more modern than SDL's web documentation.
   
2. SFML is under active development. SDL went stagnant a few years back, though it appears it may be getting reactivated again with a new release... but that's not a guarantee.
   
3. SFML uses more C++-directed design, SDL uses more C-directed design. (Contrast with SFML con #3, below)
   
4. SFML has a (small) active community that is helpful and friendly.
   

SFML cons:

1. SFML 2.0 is not officially released, though it is stable. Any SFML 1.6 question you might have often gets met with: "Use SFML 2".
   
2. SFML may be very slightly less stable, since it hasn't been used as thoroughly over the years.
   
3. In some situations, I've found SFML's overly OOP design gets in your way more than it should.
   

But most of that is personal opinion. If I was forced to use one of them on a project, and wasn't able to decide, I wouldn't complain - either is an acceptable choice. If I could choose, it would depend on the project, but SFML would probably come just slightly ahead.

Most of the time when someone swears by one of these libraries over the others it's been better for their specific situation -- which may not apply to you -- or it's simply their personal preference rather than an actual measurable advantage, or in some cases they may simply believe what they've heard from others without any actual basis.

Often benchmarks are very specific or are designed to the strengths of one API rather than another, giving the impression of better performance, but unless your own usage will very closely match the situation that was benchmarked this usually has little meaning for you as a would-be user of the library.

SFML is under active development. SDL went stagnant a few years back, though it appears it may be getting reactivated again with a new release... but that's not a guarantee.

according to the mailing list; it's for the most part finished, and Sam has stated he could ship it; but has been to busy with working with Valve for Steam on Linux at the moment; and that once he's more settled in it should be much closer to release.

Yes, but we keep on hearing it's 'almost' finished and 'close' to release - for over 4 years. We may be "closer", but until it actually is released, you can't plan on it. I fully understand things take time and life gets in the way - but when advising people on what to use, I have to add that asterisk to SDL. Don't get me wrong, it's a great API!

I have a practical situation whereby you might choose one over the other, as I have recently switched from SDL to SFML for a game I am building.

The game is a tile-based RTS, and I had developed it to the point where I had a fully functioning scrollable map + minimap + menu system. I started to use per-pixel alpha with some transition tiles that fade through varying degrees of transparency, and hit a brick wall with SDL's performance with this (a well known limitation of the library).

So I decided to give SFML a try, and converted my map engine to use this library ... and as expected the frame rate more than doubled. I'll be using SFML going forward on this project, due to the requirements of my game.

As others have said, it all depends on what you want to do. For complex alpha transparency, SDL is definitely not the way to go at the moment.

Note that if you intend to use OpenGL directly for graphics then the peformance of SDL vs SFML in this regard is not relevant, since you'll not be using them for rendering.

SFML may have a good documentation. But their website has been down for a lot of time, like more than a month, and still is, at least here in Brazil.

Are you sure you have the right address? http://sfml-dev.org/

Hmm, yes. I'm now on a different PC, and here It works now that I checked. Last week it was not working neither on the PC on my house or any other...

Must have been an issue on your end or in your area, or else just extremely bad timing coinciding with much shorter outages, the SFML site hasn't recently had any major downtime like you initially described.

It hasn't had major downtime, but it has had weird network issues. There have been previous posters on the forum asking if the SFML website was down in the last month.

[quote name='Servant of the Lord' timestamp='1352165799' post='4997827']
SFML is under active development. SDL went stagnant a few years back, though it appears it may be getting reactivated again with a new release... but that's not a guarantee.

according to the mailing list; it's for the most part finished, and Sam has stated he could ship it; but has been to busy with working with Valve for Steam on Linux at the moment; and that once he's more settled in it should be much closer to release.
[/quote]
I'd say the "close to release" thing went to waste considering it's again in the process of new features getting added =P What's already there should be safe to use though... unless you're developing for a phone, I never tried it there but it seems that on phones there are still some serious issues (not surprising, given that phone apps have a completely different environment than PC programs).

[quote name='doyleman77' timestamp='1352339935' post='4998693']
[quote name='Servant of the Lord' timestamp='1352165799' post='4997827']
SFML is under active development. SDL went stagnant a few years back, though it appears it may be getting reactivated again with a new release... but that's not a guarantee.

according to the mailing list; it's for the most part finished, and Sam has stated he could ship it; but has been to busy with working with Valve for Steam on Linux at the moment; and that once he's more settled in it should be much closer to release.
[/quote]
I'd say the "close to release" thing went to waste considering it's again in the process of new features getting added =P What's already there should be safe to use though... unless you're developing for a phone, I never tried it there but it seems that on phones there are still some serious issues (not surprising, given that phone apps have a completely different environment than PC programs).
[/quote]

SDL works great on mobile devices iOS and Android, angry birds used it when it was young and seems to be doing alright. I'm currently working on an iOS app using SDL2.0 and OpenGL for my rendering. If anyone has an issue or bug in SDL you need to report it to get a fix. You can even apply fixes yourself by posting it. If you check http://hg.libsdl.org/SDL/ you will see change sets getting added frequently.

Both SFML and SDL are great libraries though. Who knows maybe the OP is still learning so in the end it might not even matter, the experience he will gain will matter more.

Also note great improvement in rendering SDL 2.0 over the old SDL 1.2 or you could use OpenGL.

This probably isn't the thread for it so pardon me, but I've been using GLFW coupled with GLEW for OpenGL and I couldn't be any more happier. It does everything I want and nothing more. If you can't decide between the two I really suggest giving GLFW a shot

I've also found GLFW and GLEW to be a decent combination, though on Mac OS X I don't use GLEW since it natively supports the features I need. I have an OpenGL 3+ simple example of using the combo here: https://github.com/dougbinks/glewfw for Mac OS X 10.7+ or Windows.