Trying to decide if SFML is right for my project

[Steely Glint]

My friend and I are fairly experienced C/C++ developers, interested in stretching ourselves a bit with a game project on the side. I've been searching for a simple, powerful 2D graphics library for this project, with the important caveat that I am professionally a Windows developer and my friend works mostly in the Linux world. From what I've read, SFML is one of the few "game engine"-type libraries that has an implementation for both Linux and Windows.

Trying to write a cross platform application is a bit new to me, so I'm not sure what difficulties I can expect to face. My friend probably doesn't want to install Windows, so using something like Torque 2D is probably out of the question. Can SFML be used to successfully bridge the gap between Windows and Linux development? How much of a nightmare would it be to try to build an app from the ground up that functions in both Windows and Linux?

What specific advantages does SFML have over using SDL or a similar library?

Does anyone use SFML with Qt, or does it have its own way of producing consistent menus?

Thanks guys!

[eXpl0it3r]

SFML is essentially a multimedia library, which means it provides classes for audio playback, 2D rendering, simplistic networking and a few othef things.
It's using OpenGL as its backend thus enabling the possibility of cross-platformness.
The API completely hides all OS specific code, thus any true portable code using SFML can be directly taken to Linux or even OS X and it's relatively easy to setup on any supported OS.

SFML does not provide a GUI implementation, but one can integrate it with some tricks with Qt and other GUI libraries. Keep in mind though that you can't draw other widgets on top of SFML's "window"/widget.

However since SFML uses OpenGL you should be able to use any OpenGL GUI library. You might want to search for SFGUI and TGUI both community projects.

SFML is a C++ library ehile SDL is a C library. Both seem to be about equally good.

Over all I'd say, yes SFML could really be an option for you.

[Ixrec]

Having ported my program between Windows, Linux and Mac, I can tell you that the main sources of my difficulties were:

1) Disagreements between Visual C++ and g++ as to what my program should be allowed to do.  Fortunately, the errors weren't any harder to clean up than your usual compiler whining, and none of it required me to remove any actual functionality.  In retrospect most of them were Visual C++ letting me get away with non-standard behavior (like const objects in STL containers).

2) Non-ASCII strings and filenames.  SFML has some utility classes/functions for this, and the C++11 standard has quite a bit on this, but the fact remains that Windows uses std::wstrings and everyone else (at least, everyone I've checked) uses UTF-8 std::strings, and that can be a pain in the ass.

3) Functionality that neither the C++ standard library nor SFML provide.  In particular, I needed some #ifdef's around my code to create a directory, and on Mac OS I had to call some platform-specific functions to set the working directory to the executable path (for some reason it doesn't default to that).

Notice that none of these things were in any way SFML's fault, or anything SFML could have magically solved for me.

If you're interested in differences between SDL/Allegro/SFML the main ones I know of are:
- SDL is C and SFML is C++.  I'll assume you know the tradeoffs of C vs C++.
- SFML uses only OpenGL as its rendering backend and was built around it from the ground up.  SDL is older and thus still has support for old rendering methods like blitting that you'll never use anymore; arguably this makes SDL a bit outdated or less clean/modern than SFML.
- Allegro offers DirectX as well as OpenGL on Windows, if you want that choice.
- SFML has a networking module. I'm pretty sure SDL doesn't.
- SDL has force feedback. SFML has joystick support too, but not force feedback.
As you can see, some of the biggest differences I know of are things that won't matter to a lot of people.  All three are good.  Note that SFML is the only one I've actually used myself, so I may be biased.

[Steely Glint]

I count it as a point in favor of SFML that it's natively C++, since I view this project partially as a way to get some practice with boost and the new features of C++11. (Hopefully not biting off more than I can chew with a cross platform project using multiple new-to-me libraries...)

I expect boost can cover a lot of the non-graphics/sound stuff, specifically serialization and writing to the filesystem. Ixrec, what was your solution to the string problem?

I don't expect we'll be using joysticks, so lack of joystick features isn't a problem.

Thanks for the advice.

[Ixrec]

Ixrec, what was your solution to the string problem?

Because I started on Windows and ported to Linux, and have yet to refactor this part of my code, and I thought this approach was a good excuse to learn how UTF-8 worked (which it was), I have a very suboptimal solution:

//this function was written by http://www.cplusplus.com/user/Disch/
//taken from his post http://www.cplusplus.com/forum/general/31270/#msg169285
std::wstring utf8_to_wstring(const char* str);

//this function I made myself based on Disch's function above
std::string wstring_to_utf8(std::wstring line);
 

...
//tex_file is a std::wstring
#ifdef _WINDOWS
        std::ifstream ifs(tex_file, std::ifstream::binary);
#else
        std::ifstream ifs(wstring_to_utf8(tex_file).c_str(), std::ifstream::binary);
#endif
...
 

When I finally get around to refactoring this, I want to try something like:

#ifdef _WINDOWS
        #define STR std::wstring
#else
        #define STR std::string
#endif
 

I'm hoping this will be a nice easy way to remove all the rather unnecessary conversions I'm doing at the moment.

At the time I wrote that I think I was also unaware of sf::String/sf::Utf, so that might help too, but I want to use proper C++11 when I do my refactoring so I'll rely on that for my unicode solutions.  That, and using sf::String/sf::Utf will just hide/automate the conversions; I'd prefer my program simply use the right string type on each platform with a minimum of converting.



Back to the big picture: if you want to use boost, then that should make problems like this a lot simpler.  Offhand I have no idea how good their support for cross-platform non-ASCII filenames is but I'd be shocked if it wasn't there at all.  Personally, I want to avoid massive libraries like boost as long as my non-SFML needs are very narrow in scope, hence I'll be trying a STR macro or C++11 stuff or something.

You should be able to do just SFML for a long time until you run into annoying little problems like this, so I doubt you'll need to learn boost at the same time as SFML.  And SFML is almost certainly the easier one to pick up.