Please answer truthfully.

I haven't answered the poll, but I am going to post a response with my opinion:

I don't think either of them are objectively better and that it mostly comes down to personal preference. Both are pretty solid offerings which are very capable, and each has strengths and weaknesses.

It's also worth taking into consideration that a new version of SDL is currently under development that should address some of the commonly pointed-to deficiencies of the API -- most notably introducing hardware acceleration.


Strengths of SFML include:

• Modern API with a solid design which follows C++ programming idioms
• Actively developed
• Good (although basic) official documentation
• Non-restrictive licensing
• Rendering is hardware accelerated
  Strengths of SDL (1.2 -- as mentioned above, a new version is under development) include:
  
  • Lots of documentation, tutorials and sample code available online
  • Mature and very well tested. Most bugs and many deficiencies have either been eliminated or are well known with work-arounds available
  • Supports a wide range of platforms -- more than offered by SFML.
    
    
    If I were to make a recommendation to someone, I would suggest that those who have plenty of experience and/or a wealth of existing SDL code should consider staying with it, whilst I would suggest that at least until the new version of SDL is more stable SFML may be easier to get started. Anyone choosing between the would probably be well advised to take a look at some sample code and the resources available for both before making a choice based on their own preferences. Those with a good understanding of C and little experience with modern C++ may be more comfortable with SDL than with SFML. Anyone intimidated by these libraries or who just wants to get a game working quickly should consider higher-level options such as Unity or UDK.
    
    
    Hope that helps!

To upgrade jbadams' post, the new version of SDL is reasonably stable. The performance with the hardware-accelerated backends is great, and it has a couple new offerings not provided by SFML. More features are actively discussed on the forums.

SDL still supports surfaces, but now they are primarily used as a buffer before creating a texture.

The only unfortunate thing about these great new updates to SDL is that it now has a completely different rendering API, which invalidates a vast majority of the SDL tutorials around the web. However, it's still simple to get started if you're willing to read the documentation.


Now, for my personal opinion on the two:
Pro SDL:
- SDL has a simpler rendering API (both 1.2 and the new 1.3)
- The new version of SDL includes ports to Android, iPhone, and webOS; excellent potential target systems for indie games that are not available with SFML.
- D3D9 rendering backend on Windows, this will provide better performance on a typical Windows installation because Microsoft's OpenGL implementation sucks.
Pro SFML:
SFML has a simpler audio API
SFML takes advantage of C++ features, which lowers the barrier to entry.
SFML's rendering API is slightly more flexible.
Easily load GLSL files to add neat effects.

Also, as I posted in another topic, SDL and all companion libraries maintained by the SDL developers (SDL_Image, SDL_Mixer, SDL_TTF, SDL_Net, etc) are now zlib licensed, which is the same license as SFML and Irrlicht; which used to be a minor plus in favor of SFML for me.

I also want to add some points to the both libraries, as I'm also not always sure which one I should take:

SDL (1.2)
+ direct draw on surfaces: might be useful in special cases, such as emulators, dynamic images or regularly rendered maps
+ 8-bit sprites: very useful if you want to code retro-like games (such as a Super Mario fan game), as you can play with different palettes
? I'm not sure, but I think there are some problems on Windows switching to fullscreen or back during game play
- it has got it's own cursor for the window, what some people might not really like

SFML
+ native PNG and other image files support without any add-ons
+ native Ogg and other audio files support without any add-ons
+ native network support without any add-ons; simple intereface for HTTP
+ native TTF and other font files support for text drawing without any add-ons
+ multiple windows
+ fast sprite transforming (scaling, rotating etc.) without any add-ons
- might not work on every hardware where SDL does: for me it didn't work with Linux on one of my PCs
- no 8-bit sprites for playing with palette switches

I know that SFML is much faster then SDL because it's [color=#1C2837][size=2]hardware accelerated.
Here is a post about how faster it is in SFML's forum, proving it using some test:

[color=#1C2837][size=2]http://www.sfml-dev.org/forum/viewtopic.php?t=43


It shows how significant is the hardware acceleration, it can be over 9000% faster for specific things.

I know that SFML is much faster then SDL because it's [color="#1C2837"]hardware accelerated.
Here is a post about how faster it is in SFML's forum, proving it using some test:

[color="#1C2837"]http://www.sfml-dev....wtopic.php?t=43


It shows how significant is the hardware acceleration, it can be over 9000% faster for specific things.

All other issues aside, I'd argue that the benchmark in question is irrelevant (for reasons that are actually discussed in the thread itself, towards the bottom of the first page).

The results of comparing hardware-accelerated rendering to software blitting are for all practical purposes a foregone conclusion; you don't need any benchmarks to determine which will likely be faster. It's basically comparing apples to oranges, which renders the comparison more or less meaningless.

A more meaningful comparison would be to compare SFML to an SDL 1.2.x app that uses OpenGL, or to SDL 1.3 (which uses hardware rendering under the hood).

This is just my opinion and is in no way a comment on SFML or its developers, but to be honest I think that particular thread is somewhat misleading and probably isn't of much help to beginners. The argument given in the thread is that beginners won't be familiar with the underlying technical details and therefore a simple comparison of this sort is appropriate. However, it's exactly *because* beginners aren't familiar with the underlying technical details that the thread is misleading (IMO).

The comparison between SFML and SDL 1.2.x is not one of performance, but rather one of functionality. That is, SFML handles the details of hardware-accelerated rendering for you, and SDL 1.2.x doesn't. That's a legitimate observation, and could certainly be enough reason to choose SFML over SDL 1.2.x for some developers. But to compare performance in that way and attribute any significance to it is, I think, misleading at best.

Also, since SFML and SDL 1.2.x really don't have comparable feature sets, if such a comparison is to be made it should be between SFML and SDL 1.3, not SFML and SDL 1.2.x.

To be clear, I don't have an opinion regarding which API is better or should be preferred; I'm simply commenting on the thread linked to above.