SFML v SDL?

[nvangogh]

I have been looking at SDL and not only is the website well documented with clear tutorials, but there are many published books on it also.  The community appears friendly and there are forum and usenet groups. This is very important to me and appears to be lacking with SFML. I am now thinking of using SDL rather than SFML in my project. 

[mateandmetal]

 
Ok, good luck (?)
 

[pdinklag]

I have been looking at SDL and not only is the website well documented with clear tutorials, but there are many published books on it also.  The community appears friendly and there are forum and usenet groups. This is very important to me and appears to be lacking with SFML. I am now thinking of using SDL rather than SFML in my project. 

So basically, you pick SDL because it's more popular.
What does it have to do with this thread? You seem to be disregarding any benchmark test that was done...

Also, aren't we friendly? 

[Nexus]

Ok.ay But if you need help or want to discuss a specific point of SFML, ask concrete questions. Otherwise, this thread might provoke another meaningless discussion...

[eXpl0it3r]

I changed the linker settings in codeblocks and my little test program worked - fullscreen  but no way of getting out
I am going to be using sfml in codeblocks and via emacs over the next few months to learn how to use the library properly. This is the first experience I have had of C++ and a 'third party' library and that is why i am a little bit confused.

Well SDL won't be any easier to work with, imho it will be harder, but of course it has more resoruces/tutorials/books to learn things, where SFML more assumes that the user has a certain level of C++ knowledge and doesn't provide tutorials to learn coding in C++ with SFML from the ground up.
Good luck then, also this is off-topic since it doesn't have anything todo with the benchmark (maybe Laurent wants to split it [and close it?]).

[G.]

it has more resoruces/tutorials/books to learn things

Yes, but tutorials and books are useful only if you read them. 

[FRex]

So basically, you pick SDL because it's more popular.

More power to him if he can make it through but I can't believe how popular SDL is considering it's C. Who'd want that instead of sweet, sweet, sweet OOD of SFML.
On the wiki SDL has huge list of games it's in and own page while the SFML has link to non-existent page about Laurent and states that 'the team' is working on 2.0 and that 2.0 rc is only for OCaml so far(?!?!?!?).

where SFML more assumes that the user has a certain level of C++ knowledge and doesn't provide tutorials to learn coding in C++ with SFML from the ground up

I.e. questions about std, unintended integer divisions and polymorphism. 

[model76]

I have been looking at SDL and not only is the website well documented with clear tutorials, but there are many published books on it also.  The community appears friendly and there are forum and usenet groups. This is very important to me and appears to be lacking with SFML. I am now thinking of using SDL rather than SFML in my project. 

Yeah, I remember back in the summer of 2006 when I wrote my first graphical game in C++ with SDL. It was a heck of a lot of fun. SDL was quirky, but easy enough to work with for a beginner. The down side to SDL was that it wasn't being very actively developed, it had some serious limitations to what you could do with it, and it didn't even have a forum. But back then we didn't have much choice.

Then, in 2008, I stumbled onto SFML and was quickly amazed by its ease of use, the intuitive and powerful API, and the forum which was frequented and maintained by the very active developer. And the speed! Oh man, the speed... No more counting sprites or worrying about rotation and opacity. What a relief.

Anyway, if you are a beginner, I can understand why you might be a bit annoyed with SFML. 2.0 is not complete, nor are the tutorials for it, and SFML 1.6 is as dead as SDL 1.2 has been for years.

Luckily, SFML 2.0 is quickly reaching maturity, and more and more tutorials are coming in.
Also, SDL 2.0 is right around the corner, new and improved with a better license, forum and everything.

It is an exiting time in the world of multimedia libraries, indeed, and I will certainly be taking a good look at SDL 2.0 when it comes out. I have a hard time imagining the API will be as nice as SFML's, though. Maybe I'll end up using both, maybe even in the same project!

The important thing is that we now have a choice!

[Nexus]

More power to him if he can make it through but I can't believe how popular SDL is considering it's C. Who'd want that instead of sweet, sweet, sweet OOD of SFML.

You have to consider that SDL exists already a long time and was a good library in its application field there weren't many alternatives). SDL developers don't switch immediately to SFML, they have to recognize the advantages first, maybe there is also code that cannot be directly ported. But in the meantime, SFML is a known term that is often recommended in forums. Also a lot of newcomers begin with SFML, as it allows a simple, yet powerful start into game programming.

On the wiki SDL has huge list of games it's in and own page while the SFML has link to non-existent page about Laurent and states that 'the team' is working on 2.0 and that 2.0 rc is only for OCaml so far(?!?!?!?).

There have been several great games with SFML (some even commercially), unfortunately many of them are forgotten in the abyss of the project subforum. Maybe we should revive some and see what the author is doing

Yeah, I remember back in the summer of 2006 when I wrote my first graphical game in C++ with SDL. It was a heck of a lot of fun. SDL was quirky, but easy enough to work with for a beginner. The down side to SDL was that it wasn't being very actively developed, it had some serious limitations to what you could do with it, and it didn't even have a forum. But back then we didn't have much choice.

Then, in 2008, I stumbled onto SFML and was quickly amazed by its ease of use, the intuitive and powerful API, and the forum which was frequented and maintained by the very active developer. And the speed! Oh man, the speed... No more counting sprites or worrying about rotation and opacity. What a relief.

Hey, I experienced exactly the same story, even the years coincide. In 2006, I began to write my first little games with SDL, and had a lot of fun. But I soon recognized that functionality like rotating or colorizing sprites became more difficult, also I had to optimize the hell out of my tile rendering to keep a reasonably running program. I remember how I wrote complicated logic to clear only parts of the screen

Correspondingly amazed were I when I stumbled upon SFML in 2008 and found out that everything I had done were possible in a much easier and faster way. I could clear the whole scene! A short time later I came across many other features I didn't know at SDL, and the choice was definitive. In 2012, I still follow SFML development actively, I have also written an extension library to simplify common tasks. Although I plan to take a deeper look at 3D games in the future, I will most probably continue to work with SFML for other parts like Audio or Networking.

[model76]

I remember how I wrote complicated logic to clear only parts of the screen

Haha - was it the dirty rects scheme? I remember that being very popular. Must be thousands of implementations out there. Personally, I just had my fun within the limitations of the library, and my abilities I suppose.

Correspondingly amazed were I when I stumbled upon SFML in 2008 and found out that everything I had done were possible in a much easier and faster way. I could clear the whole scene! A short time later I came across many other features I didn't know at SDL, and the choice was definitive. In 2012, I still follow SFML development actively, I have also written an extension library to simplify common tasks. Although I plan to take a deeper look at 3D games in the future, I will most probably continue to work with SFML for other parts like Audio or Networking.

Yeah, I remember you well from back then, Nexus. You have always been very active in this community. I am also well aware of Thor, as well as a fan, and plan on making extensive use of it in the future!

One often overlooked feature of SFML, I feel, is the ability to simply look at its code. One can really learn a lot from that. Not that you can't do that with other libraries, but SFML is just so well structured and easy to read. I know it probably sounds corny, but I find it really beautiful. Like a piece of art.

As for 3D games, well, I don't know. I enjoy playing them, but I was always fascinated with the possibilities that lies within the limitations of 2D.

Anyway, I am really exited about the prospects of SDL 2.0, and what it will mean for everyone and for SFML. Liberal license open source competition means that the developers can look at each others work and take ideas. Cake for everyone, especially the users!
I also have a sneaking suspicion that SFML plays some part in the sudden velocity of the SDL development, as well as the way the devs communicate with their users.

[N_K]

Well, here's my opinion. Both SDL and SFML has their own pros and cons. I developed my first "game" using SDL, and if SDL had proper per-pixel alpha blending (I didn't much care if hardware accelerated or not), I would probably still use it. It has more tutorials, because it has been around for a very long time (it started around 1997, I believe). It has a big community for the same reason. However, it's biggest problem seems to be that it's software renderer is too slow for certain things (it lacks certain blending modes as mentioned above, as well as some sprite transformation capabilities), and, while it can co-operate very well with OpenGL, setting this up is nowhere as beginner friendly as using the software renderer.

SFML is based around OpenGL, so you don't have to worry about setting these things up. It has all the things needed for simple games, and it can be extended with a little effort (even if I'm a beginner, I was able to set up CEGUI to work with it, for example). However, since I got used to SDL during the years, it was quite hard for me to get the things going, because, although SFML does the same things as SDL (and some more) it does them in a quite different way. Originally, I wanted to port my old code to SFML, but in the end, I decided it doesn't worth the effort, and now I'm rewriting everything from scratch.

My advice is to take a look around all the different libraries: Allegro, ClanLib, Gosu, SDL, SFML (in alphabetical order, don't start a flame war over this  ), and chose the one that suits your needs and skills the most. Don't settle with one just because "more people use it", or "has a larger community", or "has cooler screenshots".

[FRex]

There have been several great games with SFML (some even commercially),

The way I found SFML was reading blog of creator of Atom Zombie Smasher few months ago about his engine where he mentioned 1.5 and 1.6.

One often overlooked feature of SFML, I feel, is the ability to simply look at its code.

The amount of layers of abstraction in SFML code and the polymorphic drawable class are just.. wow..
There could be no texts, sprites, shapes and vertex arrays and anyone could easily write them without opengl knowledge because of the way draw methods, vertices, transforms and states work.

[Stauricus]

as i'm new to programming in general, i've tried some engines like SDL and SFML, to see wich one is the best.
honestly, both seems to be good. but SFML has many functions that i didn't found in SDL. and is a little easier, too. so...

[Mario]

I think the main difference is the fact that (classic) SDL is based on C code without classes and stuff. In addition to this, SDL is split into several libraries, even for just some basic/common task (display some TTF text and play sounds) you'll need at least 3 libraries. You do so as well for SFML, but you get everything in one packet.

I remember trying SFML for the first time and I liked it instantly, despite the bad sprite performance (which is solved with 2.0) compared to manual drawing/OpenGL.

[eXpl0it3r]

In addition to this, SDL is split into several libraries, even for just some basic/common task (display some TTF text and play sounds) you'll need at least 3 libraries. You do so as well for SFML, but you get everything in one packet.

The big difference with such 'modules' is that the diffrent libraries in SFML are only split, to make it possible to diffrent users, to just use a part of SFML (graphic stuff, window creation, audio only, etc.) and everything comes from the one source, thus the split is actually just a logical one. Whereas with SDL, all the modules are maintained by diffrent developeres, with diffrent coding skills and diffrent coding guidlines and the only way to provide a further functionality is by creating a new library, thus the split is forced and the codebase can never really be clean.