next »

[Aquin]

You'll notice a trend here:

"I never really used SFML, but SDL isn't too bad once you do this this and this."
"I used SDL until I used SFML and now I'd be crazy to go back."

 

[CyanPrime]

You'll notice a trend here:

"I never really used SFML, but SDL isn't too bad once you do this this and this."
"I used SDL until I used SFML and now I'd be crazy to go back."

 

Just like Windows and Linux 

[Gold Cray]

I use SDL for input and for handling windows, and I use openGL for graphics. I've never looked into SFML. SDL input kind of bugs me, so maybe I'll check it out.

[BrianSlipBit]

I'm a recent SFML convert as well.  About a month ago I finished porting my engine back to C++ from C#.  I evaluated SDL, but 1.3 (I think) had too many issues that still needed to be resolved.

I checked out SFML and found it is really well put together.

However, I think one of the biggest selling points for SFML is its licensing.  It's completely free.  I believe it uses the zlib license.

Here's what I had to say at the time: http://www.darkflowstudios.com/entry/simple-and-fast-multimedia-library

[J.G. Martins]

but i found out i was more interested in creating games than reinventing the wheel writing wrappers. So i switched to sfml.

This is the main point for me.

[Mikademus]

I like to test and compare alternatives before I got with a new frameowork and simply put: given the amount of endorsement here, SFML would definitely be among the alternatives.

[Glaiel-Gamer]

i use SDL just for opening a window and reading input (and threads)

I'm probably gonna replace it with my own wrapper over time just to get rid of the dependency since I'm using it for almost nothing.

[Martin 2BAM]

Yeah, don't get me wrong.  I used SDL for the longest time. I used SFML *once* and never looked back.  It kinda makes that sort of impact on you.

Exactly.

SFML works for Windows/Mac/Linux. It's thought for OOP (Great interface, almost no wrapping/bridging needed).

Also, I think it's better to prototype:
* Per se encapsulation with lots of properties
* Sprite with angle, size, color.
* Text class (Loads transparently TTF through FreeType2), starts by default with an arial font. You can start placing text on screen with 2 lines of code.
* Positional 2D audio (Sound uses a subset of OpenAL to avoid entering into specific details like 3D and wave decay functions, etc)
* Straightforward, simple, "all in one place" input system and networking
* IntelliSense helps a lot, when you don't know something you can crawl the methods of a sprite instead of the whole function set.

[BrianSlipBit]

The only real "problem" I've encountered so far with SFML is that if you dynamically link with it, it crashes on exit (only on ATI cards I believe) when trying to release the global OpenGL context.  The work around is to statically link with it.

Regardless, I would not consider that a show stopper.

Oh, and it would be nice if it would allow you to provide a custom memory allocator.  It does use STL, which I'm not really a fan of.  However, I'm assuming that there are relatively few allocations that occur in order to create a window and an OpenGL context.

[SimonLarsen]

Goddammit. I was finally starting to get really familiar with SDL and now this?!

How can I not have heard about SFML before? Seems like the perfect choice for me. Oh well. Seems like the transition will be rather painless at least.

[increpare]

Okay bitches, I'll give SFML a try tonight

edit: got the example compiling
edit: there's a bug whereby autocomplete doesn't work with SFML and XCode. A problem with the latter rather than the former, but it's still a major inconvenience.

[Martin 2BAM]

The only real "problem" I've encountered so far with SFML is that if you dynamically link with it, it crashes on exit (only on ATI cards I believe) when trying to release the global OpenGL context.  The work around is to statically link with it.

I traced that problem 2 years ago and ended up being some sort of global variable trying to access the OpenGL context when it was dead (I think it had to do with the default font)
The author is really stubborn, and didn't accept the reason saying that "that shouldn't happen". Anyway, removing one line solved it for me, keeping the OpenGL context alive until the process dies.

Nevertheless I found it to be better to static link everything always to avoid deployment problems, even if you end up with a 30 MB executable (e.g. WinXP's "descriptive" message for a mismatched CLR is "The program is misconfigured, try reinstalling"   )

[MrGando]

I'll have to say SFML.

I used SDL for several years until i needed better performance and support for scalable/rotatable graphics. Then i tried using sdl with opengl for some time. I got a incredible boost in performance, and managed to rotate, scale etc, but i found out i was more interested in creating games than reinventing the wheel writing wrappers. So i switched to sfml.

After using sfml for about two weeks i already like it better than sdl. Only thing i fear i'm going to miss is the sdl_mixer and it's support for mods and midis.

I also remember having trouble switching between video modes in sdl. This seems really easy in sfml.

I experienced exactly the same issues... now using C++ and OpenGL, ended up playing and writing my own Engine etc... still in construction, but a great way to learn if you want to go deep :-)

[JamesGecko]

I traced that problem 2 years ago and ended up being some sort of global variable trying to access the OpenGL context when it was dead (I think it had to do with the default font)
The author is really stubborn, and didn't accept the reason saying that "that shouldn't happen". Anyway, removing one line solved it for me, keeping the OpenGL context alive until the process dies.

I dunno. If the author prefers to leave a visible bug in the library for two years rather than admit he was wrong... that kinda throws up some warning flags for me.

[Martin 2BAM]

Hehe
The interface is the best, ever... even if the implementation is not that good.
To be fair it's really well maintained and his stubborness also happens to serve the purpose of not generating a bloated API for every request that's made.

I can only say you should give it a try, hack the tutorials and play with that to get the feel of the library.

Regards

[BrianSlipBit]

I dunno. If the author prefers to leave a visible bug in the library for two years rather than admit he was wrong... that kinda throws up some warning flags for me.

Well to be fair, more recent discussion on the SFML forums with the author indicate that it's a rather difficult problem to fix because of the way the system was designed.  Thus, he decided to leave it alone for now.  I don't know if that's complete BS or not, because once I stepped through the code enough to see where it was crashing, I didn't dedicate anymore time to it other than seeing what was said on the forums.

Is it annoying?  Yes.  Can I live with it, considering there is a work-around?  Yes.

I would like to see it fixed, but not if other more useful features and/or bugs can be implemented/fixed first.

[BlueSweatshirt]

In case anyone's curious, this is the topic BrianDFS was referring to:(I believe, at least)

http://www.sfml-dev.org/forum/viewtopic.php?t=2566

[increpare]

Okay, I might be converted - the ease of using shader extensions is great.

[oahda]

About the problem with crashes in Windows on exit: using exit(0) instead of window.Close() works fine (but I don't know if this properly clears the resources; I don't seem to have the problem since I started compiling the Windows version in Linux rather than actual Windows, though, so I'm guessing it has to do with the default way of linking, after reading this topic).

[increpare]

Okay I'm a convert.