Missing general information

[CGars]

Although this is my first post here I've been around the forum for two years. I might have missed this information but what I really miss here under General discussions (and that often seems to be asked by newcomers) is the following stickied posts:

• The longterm goal of SFML: is it meant to be used for small hobby projects or is it a serious alternative for SDL meant for creating professional 2D games?
• A clear roadmap for the next major version of the library and hopefully a rough timetable.

I really like SFML and would love to use it for a professional game but the uncertainty of what and when features will be added and bugs fixed makes me a little hesitant. Things like issues 1 and 7 still being open 5-6 years after reported/first discussed.

Anyway, this is meant as suggestions to help improve the library so I hope I don't come off as too negative.

[sjaustirni]

I'm not Laurent, nor am I on the SFML team, I am just a regular user, but I think the answers are obvious enough for anyone to write.

• SFML is absolutely meant to be used in hobby and professional applications in general (games and multimedia applications mainly, as it says on the front page), 2D or 3D. It's called simple, not limited. In fact, SFML has been used in various Steam games, just browse the SFML projects section for details.
• For discussion on the major versions we have dedicated threads here on forum, as plenty of features are firstly discussed and only then the plan for their implementation is made. There is, however, usually Project section on Github for the upcoming release, major or minor, where you can see how it is going with the implementation of the particular features.

In conclusion, if you need the support for particular platform which happens not to have official SFML support, go for SDL or the like. Otherwise you should be good with SFML. SFML is mostly stable and the development is much faster compared to SDL or Allegro. The #1 and #7 are feature requests, not bugs. Feature requests may be left open for a longer time since sometimes it is not clear what implementation would be the most appropriate, or even, if the feature is in the scope of the project at all. Sometimes the reason for them being open is just that there are more important things to work on, as it is the case with #1.

[CGars]

• For discussion on the major versions we have dedicated threads here on forum, as plenty of features are firstly discussed and only then the plan for their implementation is made. There is, however, usually Project section on Github for the upcoming release, major or minor, where you can see how it is going with the implementation of the particular features.

To me there is a big difference in 21 pages of the users' wishlists and what Laurent & team are actually planning on doing, and the project section on Github again does not give much longterm information to go on.

In conclusion, if you need the support for particular platform which happens not to have official SFML support, go for SDL or the like. Otherwise you should be good with SFML. SFML is mostly stable and the development is much faster compared to SDL or Allegro. The #1 and #7 are feature requests, not bugs. Feature requests may be left open for a longer time since sometimes it is not clear what implementation would be the most appropriate, or even, if the feature is in the scope of the project at all. Sometimes the reason for them being open is just that there are more important things to work on, as it is the case with #1.

I know they aren't bugs per se, but at least in my view they are rather big omissions if you want to make a professional application/game. I've had problems myself regarding the keyboard issue (I'm on a Swedish one) and I've had to do some ugly workarounds regarding issue 1 when it comes to implementing a proper gui system for instance. They might not be the most important features but in my view they are not so small as to not prioritize them for 5-6 years.

[sjaustirni]

To me there is a big difference in 21 pages of the users' wishlists and what Laurent & team are actually planning on doing, and the project section on Github again does not give much longterm information to go on.

Indeed. Bear in mind, however, that we're still working on 2.5. SFML 3 is not going to be released anytime soon, AFAIK. I would argue that it is not yet clear what exactly is SFML 3 going to be like, even though some issues have been discussed and agreed upon in the aforementioned thread. If there's a major feature you miss in SFML 2.5, you should absolutely try to find an alternative to SFML, or work on it, see below.

I know they aren't bugs per se, but at least in my view they are rather big omissions if you want to make a professional application/game. I've had problems myself regarding the keyboard issue (I'm on a Swedish one) and I've had to do some ugly workarounds regarding issue 1 when it comes to implementing a proper gui system for instance. They might not be the most important features but in my view they are not so small as to not prioritize them for 5-6 years.

It seems that no one had actually enough  interest in the recent years to successfully implement the features. You see, this is unpaid open-source. People come and work on the issues as they see fit, usually on the features they need. If you find there's an unreported bug, send a bug report. If there's a bug you want to fix, but no one seems to care about it, you're very welcome to open a pull request and try to fix it.

Sure, there are people who take care of bug reports that are not related to their project, but there's only so many of these volunteers and their time is limited as well.

P.S. I just found myself explaining how an opensource project works the second time in a short time, maybe it'd be useful to have a sticky post with an explanation of what does it mean to use an opensource library like SFML

[Hiura]

Let me add a few things on top of what sjaustirni said.

Since it's an OSS, we all invest a bit of our free time in SFML. But the actual amount of time varies a lot depending on other life factors, obviously. When we fancy implementing something or fixing a bug, we do it. But this is limited by several factors: do we have enough information about a bug to reproduce it and do we (technically) know how to fix it? When implementing new features, it's always hard to know exactly what is meaningful to add to SFML. And so on...

We've setup a few guidelines to help the community contribute back to SFML. See them here: http://www.sfml-dev.org/contribute.php Mainly, it gives the overall picture of what SFML is and what it isn't. Based on that, if you feel some features are missing you can make your case on the forum, but you must be ready to "animate" the debate, make sure progress is made in the discussion and ideally be capable of providing an implementation when the feature is accepted and the general API is defined and agreed upon.

Regarding the long term vision of SFML: we internally have some discussions about what SFML 3 will look like, based on the feedback given on the forum and elsewhere and our personal visions. The main idea for v3 is to work on breaking changes (e.g. modern C++ API, better & more recent OpenGL features). But working on v3 will take some time and doesn't imply that we should dead stop working on v2 now -- bug fixes and some features can still be implemented before v3 is released. (Some more information regarding v3 development will be released soonish.)

So if you want to see something be included/improved in SFML, please open a specific thread and be proactive with it. Any help is more than welcome! 

[eXpl0it3r]

I think most points have already been addressed, however here are a few extending comments.

The longterm goal of SFML: is it meant to be used for small hobby projects or is it a serious alternative for SDL meant for creating professional 2D games?

We're not trying to be just another alternative to library X. We're not providing feature sets based on what other libraries do, instead SFML is developed while always keeping its own name in mind: Simple, Fast and Multimedia. Whether something gets added to SFML largely depends on whether it fits into the scope of SFML, whether it has real use cases and whether there is someone willing to help implement it.
What is a "professional 2D game" and what requirements do you have for a multimedia library implementing a "professional 2D game"? What makes SDL more "professional" than other libraries?
If all you need is a list of "professionally" created games, you may check out some of the titles listed on Wikipedia, which by now is already missing some titles such as Dispersio or Remnants of Naezith or CUIT.

A clear roadmap for the next major version of the library and hopefully a rough timetable.

There have never been time estimates and there never will be, because it's impossible to fulfill. Everyone who works on SFML is doing so voluntarily and in their free time. We can't force people to spend x-amount of hours on SFML to fulfill goal XY.
If you're interested to see what we've roughly planned for the next version, you can check the GitHub milestones and GitHub projects.
Additionally, we've just opened a new sub-forum dedicated to discussions on SFML's development.

I really like SFML and would love to use it for a professional game but the uncertainty of what and when features will be added and bugs fixed makes me a little hesitant. Things like issues 1 and 7 still being open 5-6 years after reported/first discussed.

As mentioned by Hiura, the fastest way to get a feature or bugfix into SFML is by being active on your end.