SFML community forums
General => General discussions => Topic started by: cepro on August 09, 2014, 04:08:18 am
-
http://www.reddit.com/r/gamedev/comments/2cywca/why_do_so_few_games_use_sfml/
-
I read over this, a large part of the general consensus was not enough cross platform support and issues with the internal opengl calls being outdated. I think someone also mentioned the lack of support for VBO's too.
-
Very interesting post.
Finally some feedback from people who have tried SFML as well as other libraries. Such discussions can unfortunately only be found on such "meta discussion platforms" and not on dedicated forums such as this one.
Most of the points mentioned there are probably already known here on this forum, but I'll try to sum them up anyway for those who don't want to read the whole discussion.
- SFML was late to the party, compared to SDL.
- Other libraries (SDL) have connections to the big players (e.g. Valve).
- Some people just prefer a C API.
- SFML doesn't support as many platforms as some would like.
- SFML graphics' use of deprecated GL scares people.
- SFML graphics' inefficient use of GL scares people.
- SFML context management scares people.
- SFML doesn't support core-only contexts.
- SFML doesn't support raw input.
- People want more frequent releases to convince them stuff is happening.
- SFML doesn't support higher level features that some other libraries do.
I'll try to comment on each of them now.
- This is a general problem in game development. Positive feedback. Once something starts rolling, it will take something really catastrophic to stop it from gaining more traction. Windows vs Other OSs, DirectX vs OpenGL and SDL vs SFML. Considering SDL is more than 10 years old, it had a significant head start and thus the amount of people who feel safe using it will naturally be larger. Just search for books about SDL compared to books about SFML ;). The fact that universities and schools promote SDL in their game development camps doesn't help the situation either. What can SFML do in this department? Not really all that much. It is very hard to counter the positive feedback issue, especially if you have limited resources (people/money). We can only hope that its benefits can one day outweigh the insecurity some people have when trying something different.
- Basically same as the previous point. Nothing SFML can do here. Just like every other sector, companies invest in something that will benefit them in the long run. It is kind of obvious that Valve is backing SDL because they want to boost Steam sales on platforms besides Windows, especially considering Steam Machine and SteamOS are right around the corner. If you want proof, look at the videos from the Steam Dev Days 2014 (https://www.youtube.com/user/SteamworksDev/videos). If it isn't obvious enough in what direction they are going, then I don't know what is.
- Probably a minority, and if you ask me, SFML really shouldn't try to cater to people trying to develop modern multimedia applications in C anyway ;).
- A side-effect of the first point. Considering SFML started out with Windows/Linux/OSX and already has somewhat usable support for iOS and Android, this will become less of an issue in the future. There will probably always be people who want ports for non-OpenGL platforms, and unless SFML decides on writing a rendering backend using another graphics library, that probably won't happen. You have to balance between good morals and the urge to expand the user base.
- This is something that can (and probably will) change in the (hopefully not to distant) future. I already demonstrated with my proof-of-concept 3DEE (https://github.com/binary1248/SFML) that this is possible without breaking the public API. The changes required were substantial, and thus it will probably take a while to get into mainline SFML, but it is possible.
- This has a bit to do with the previous point. Legacy OpenGL was "designed to be used inefficiently", that's why it was deprecated. As with the previous point, moving to modern OpenGL should alleviate most of the efficiency concerns, as far as the API allows. Higher level features (like sprite batching) that implicitly or explicitly improve performance were never part of the SFML API, since the API is about providing the necessary access points to lower level functionality. Such high level features can already be built on top of SFML, and people who complain about the lack of such features and thus the implied inefficiency of SFML are simply too lazy to roll their own code and probably just spoilt by other libraries that do go ahead and provide such features. SFML performance scales with the aptitude of the programmer, and that isn't a bad thing.
- This is a known issue for more "serious" developers. For beginners this makes no difference whatsoever and thus it was a negligible point until now, but it tends to get annoying once you are actually aware of contexts and their implications which is a requirement of modern OpenGL programming. This might change in SFML 3, so this point would have to be re-evaluated then.
- This is already implemented in the gl_dev (https://github.com/SFML/SFML/tree/feature/gl_dev) feature branch and undergoing testing.
- This is currently being evaluated, see here (https://github.com/SFML/SFML/issues/304) and here (http://en.sfml-dev.org/forums/index.php?topic=9426).
- This change has already taken place. 2.2 should be released in the near future, and 2.3 shouldn't take as long as 2.2 did ;). But really, people should come out of the mentality of "we should only use officially released libraries", although it is understandable when developing a commercial product and having management constantly breathing down your neck ;).
- This is a point that pops up quite often, see here (http://en.sfml-dev.org/forums/index.php?topic=15027.0) for examples. Many people think that SFML should provide a "complete package" for them to start development of their own game and every single convenience function that one can think of should be part of SFML. This is not the core idea of SFML. SFML provides access to low level functionality. It is up to you to do something with that access. If you can't do something with the access provided by SFML, that is a legitimate issue and something that can be discussed, as is often the case. If you can't do something that can be done using the access provided by SFML, you either have to write it on top of SFML or hope there is a library that has already done so. People often compare SFML to other libraries in this aspect. You always hear things like "But library X does Y, so SFML should do so too". I don't think these requests/suggestions are valid, and if the individual threatens to drop SFML for another library that does whatever it is they need, then so be it. SFML was never designed to be "just another library like X" or "X with a C++ interface". The fact that SFML often gets compared to SDL does not imply that SFML is trying to be like SDL, it just shows that the subset of low level features that both libraries provide access to is so similar, people naturally base all their comparisons on that. Going forward, SFML might even provide features that are completely orthogonal to the features of other libraries and thus a direct comparison would be like "comparing apples and oranges" although that is what people will end up doing for a long time anyway because they simply don't want to understand. The growing amount of extension libraries that get written on top of SFML is an indicator of how extensible and modular it was designed to be. You probably won't find that many "extensions" written for other libraries since either a) the feature is already part of the main library, or b) the library makes it painful to write extensions for it. Just as an example: compare the way the library files are structured among the libraries. SDL comes in 1 monolithic "all-in-one" file, like many other libraries. In contrast, SFML decides to structure its library files in a modular way, so you can link and include whatever you will need in your project. This idea can be extended to the extensions as well. Get and use whatever you need, no more and no less. Sure, it takes a bit more time to set up, but considering that it is an O(1) operation per project, and will probably end up saving on build time, you will profit from it in the long run. People just don't look past the short term costs/results. SFML has its own philosophy, and people have to realize that being different isn't always a bad thing.
SFML still has a lot of room for improvement. Its development will probably pick up pace as well, since there are more helping hands available now than there were a year ago (Laurent can be attributed to almost all of the development besides OSX prior to the formation of the SFML team). SFML 3 will probably alleviate many of the "issues" that the people who posted in that discussion have with SFML, but it will never really "replace SDL". The only way SFML will ever take over is if people start to think out of the box and try new things, go against the "norms" and just stop comparing SFML directly to SDL. This last point can be made easier if SFML were to provide features that SDL is just unable to provide due to its nature, and that is an advantage that SFML has over SDL. It can adapt and be more liberal than SDL will ever be able to, because all the "old dogs" and "positive feedback people" are camping there and will probably start to cry if SDL were ever to "do something like SFML".
-
Higher level features (like sprite batching) that implicitly or explicitly improve performance were never part of the SFML API, since the API is about providing the necessary access points to lower level functionality. Such high level features can already be built on top of SFML, and people who complain about the lack of such features and thus the implied inefficiency of SFML are simply too lazy to roll their own code and probably just spoilt by other libraries that do go ahead and provide such features. SFML performance scales with the aptitude of the programmer, and that isn't a bad thing.
Maybe it's just me, but I think you guys would want SFML to perform as fast as possible, regardless of how skilled the programmer using the library is.
In regard to a feature such as sprite batching, is the concern not wanting to clutter the API, or is it more that it's not considered low level enough to implement?
-
- SFML was late to the party, compared to SDL.
- Other libraries (SDL) have connections to the big players (e.g. Valve).
- Some people just prefer a C API.
- SFML doesn't support as many platforms as some would like.
- SFML graphics' use of deprecated GL scares people.
- SFML graphics' inefficient use of GL scares people.
- SFML context management scares people.
- SFML doesn't support core-only contexts.
- SFML doesn't support raw input.
- People want more frequent releases to convince them stuff is happening.
- SFML doesn't support higher level features that some other libraries do.
- Can't be changed, but if the new thing brings better features it can still get users.
- Yeah, many things get adopted cause of marketing.
- It is better for the newer competitor to find its own niche and if everyone else does C only its nice to have someone provide C++. The C binding SFML got is still there, but should not be the main project.
- That seems to get improved now?
- It looks so clean from outside, but if you look inside the box and get to know too much...
- Maybe it would be a good idea to rewrite the graphics part to use only VBO and batch things internally someday.
- Rip that hack out please and require people to create a context explicitely when needed.
- Shouldn't be too hard to have this in the window part at least.
- Some others dont have that too, but a few people will always nitpick for minor gains.
- That important bugfixes get not released while some unrelated new feature is not ready is a constant annoyance for me, too. It would be so easy to keep a separate branch for bugfixes only for the latest release and merge it back into master regularly where new features can be experimented with. Then just put some tag on the bugfix branch if enough bugs or some annoying bug got fixed and recompile, announce for example 2.1.1.
- People will always want more features without even knowing if they really need them or just cause of lazyness to include another library in their project. Then if some library gained too much bloat it will get abandoned for something that is more easy to understand. :)
-
Maybe it's just me, but I think you guys would want SFML to perform as fast as possible, regardless of how skilled the programmer using the library is.
The library is already designed to operate as fast as it can without sacrificing any of its interface design. The fact that it currently limits itself to the legacy OpenGL API comes from its history and considering that ancient hardware might not be able to provide anything else is another factor to consider. What people tend to forget is that SFML currently only has a single rendering implementation, that it uses for all platforms. It was probably previously infeasible for Laurent to support multiple rendering implementations by himself which is why he restricted SFML to merely supporting what was necessary to get consistent results from SFML no matter what hardware was in use.
Like I said, this might and probably will change in the future because a) SFML now has more development resources at its disposal and b) more and more people (even beginners) are putting more value into using the modern OpenGL API and coupled with the fact that the hardware that doesn't support it is becoming less and less common, SFML will have to start making changes that target future hardware that might not even provide the legacy OpenGL API any more.
In regard to a feature such as sprite batching, is the concern not wanting to clutter the API, or is it more that it's not considered low level enough to implement?
Both. For me, you can separate API levels into 3 categories. Low, middle and high. A low level API would be just 1 step above the operating system, common examples include OpenGL, OS socket APIs and OpenAL (although this is debatable). Mid level APIs are normally focused on taking the low level APIs and providing some benefit over them. In the case of SFML and SDL, it is the portability that such libraries guarantee. They abstract away the differences between the low level APIs that operating systems bring along with them, easing the development of cross-platform applications. This does not mean that they are limited to providing a thin wrapper on top of said low level APIs. They can also provide helpful functionality that encompasses the wide majority of use cases developers would have when usually resorting to the lower level APIs.
SFML tries to satisfy the perceived needs of its target audience which in turn means that almost all of their legitimate use cases will be covered by the library in one way or the other. This is where things get a bit more complicated. Until recently, its target audience consisted of people who were merely interested in simple 2D graphics, simple audio and rudimentary network access. It had been this way for years, which is why the API ended up being like it is now. I can't speak for Laurent, but I can imagine he simply didn't know that there were many people like those who posted in that reddit discussion that found SFML lacking the features that they would need to consider using SFML seriously. I have been a proponent for expanding SFML's perceived target audience for years, but I haven't gotten much backing, since people who shrug SFML off often don't even mention why they do it. That reddit discussion contains more information from such people than you will find on this forum in the last 3 years.
I think SFML succeeds at doing what it was originally designed to do, provide simple access to multimedia and networking for beginners to have a bit of fun with. Going forward, I hope Laurent recognizes that SFML has much more potential if it were to open up to a bigger audience, which would mean it has to provide features that the new audience also seeks without sacrificing any of the values or ideas that make it the library it is today. It is going to be tricky, but I'm pretty sure it isn't impossible.
As for the question at hand, taking into consideration what I just said, sprite batching simply wasn't a feature that would benefit SFML's target audience enough for it to become a core feature of SFML. It could always be built on top of SFML, which is why it never really had a high priority, and that would also keep the core API clean for those who didn't need it. One might argue that having API documentation pages that are hundreds of pages long because of all the auxiliary features isn't a bad thing, but considering that we urge beginners to browse the documentation to learn more about how to use SFML, it isn't that friendly either. Just like the C++ standard library, we like to keep the API concise. It has just enough for you to build arbitrarily complex things on top of it, no more and no less. This way, we can also keep an overview of the feature set that SFML is meant to support. A mid level API really isn't destined to become too huge, and is often smaller than the lower level API which it is built upon. If we expanded SFML to encompass higher level features as well, it would just explode. People might start asking "but you included feature X so why not include feature Y too?" which would lead to a chain reaction and ultimately API bloat.
Since there isn't anything else higher than "high level" it can and often does include everything all the way to very domain specific features which really shouldn't have a place in a general purpose multimedia library. This can be seen in many other libraries out there. People might adore them for exactly this reason, but they tend to forget that if they look around at the others who also use said libraries, they all tend to come from the same domain for exactly the same reason as well. I don't know about you, but I can hardly call such libraries general purpose any more.
-
Fair enough. Thanks for the response.
-
people who shrug SFML off often don't even mention why they do it. That reddit discussion contains more information from such people than you will find on this forum in the last 3 years
You ask someone to give their honest opinion, even (and especially) if it includes the negative points, and they'll refuse to answer, knowing that they're helping; people don't like to help.
You have one person make an insult towards something - or even just create an opening for such - and it'll snowball with everyone firing what they can, feeling more confident in their insults by the fact that others have already said them.
EDIT: added the word "create".
-
Reviews are much better for the SFML than for the SDL, that's why I've choose it. It is enough to convince me.
-
@Hapax : I think you may want to rethink that comment and try again. At least to me, what you said seemed a bit incoherent and inconclusive.
I personally think there's a lot of positive feedback to take away from that reddit discussion. There's also a lot of criticism of SFML and some of it is justified.
To make SFML better, both the good and bad needs to be heard.
-
Added the word that was missing from my sentence. Thanks, Jesper.
-
I thought this was funny: "SFML is slow, very slow, and the API isn't really that clean. It's so heavily OOP it doesn't feel natural to use and is more suited to a Java application."
While some of the points are valid, I think a simple explanation of why SFML isn't more utilized is marketing. SDL and many of these other libraries have had time and usage. People see the SDL logo or "Made with SDL" so over time it's developed rapport. Unfortunately SFML hasn't had this publicity yet so dismissal is easy. We all know SFML>SDL any day :P.
-
I thought this was funny: "SFML is slow, very slow, and the API isn't really that clean. It's so heavily OOP it doesn't feel natural to use and is more suited to a Java application."
I don't find it funny at all.
Did the person who wrote that post refer to benchmarks to support his statement that SFML is slow? Or is it just his opinion? To me it looks like an assumption.
As for SFML's API, my opinion is that the API is clean, and I quite *like* the OOP approach; it *feels* natural. But I know that many seasoned game programmers prefer to use C++ as "C with classes" and eschew most OOP paradigms; such programmers may well prefer SDL, since it's a C library and as such is well suited for programmers that prefer to limit OOP usage to the bare minimum. Maybe they should try and use SFML's C binding.
While some of the points are valid, I think a simple explanation of why SFML isn't more utilized is marketing. SDL and many of these other libraries have had time and usage. People see the SDL logo or "Made with SDL" so over time it's developed rapport. Unfortunately SFML hasn't had this publicity yet so dismissal is easy. We all know SFML>SDL any day :P.
If we use the criterion of the number of released games built with each library, that is debatable; since I don't have numbers nor know for any recently released title why either library was decided for or against, I won't spout an assumption. Like @binary1248 said, it's like comparing apples to oranges. What I *can* state is, I've used both libraries and I can honestly say that I prefer SFML, because I find it more suited to the way I work.
-
I thought this was funny: "SFML is slow, very slow, and the API isn't really that clean. It's so heavily OOP it doesn't feel natural to use and is more suited to a Java application."
I don't find it funny at all.
Did the person who wrote that post refer to benchmarks to support his statement that SFML is slow? Or is it just his opinion? To me it looks like an assumption.
As for SFML's API, my opinion is that the API is clean, and I quite *like* the OOP approach; it *feels* natural. But I know that many seasoned game programmers prefer to use C++ as "C with classes" and eschew most OOP paradigms; such programmers may well prefer SDL, since it's a C library and as such is well suited for programmers that prefer to limit OOP usage to the bare minimum. Maybe they should try and use SFML's C binding.
I think you missed my point: it was funny because of how ridiculous of a statement it was. I completely agree, the OOP approach feels very intuitive and I don't see how much cleaner the API can really be. Calling SFML slow and unclean is probably coming from one who dislikes C++. Odds are he's one of the guys that don't like C++ and share the Linus philosophy.
While some of the points are valid, I think a simple explanation of why SFML isn't more utilized is marketing. SDL and many of these other libraries have had time and usage. People see the SDL logo or "Made with SDL" so over time it's developed rapport. Unfortunately SFML hasn't had this publicity yet so dismissal is easy. We all know SFML>SDL any day :P.
If we use the criterion of the number of released games built with each library, that is debatable; since I don't have numbers nor know for any recently released title why either library was decided for or against, I won't spout an assumption. Like @binary1248 said, it's like comparing apples to oranges. What I *can* state is, I've used both libraries and I can honestly say that I prefer SFML, because I find it more suited to the way I work.
I too have used SDL and made the switch to SFML. I found it more straightforward and intuitive. The "modern" (don't kick me) feeling and approach to things as well as focusing on C++ over C made me switch. Also, hardware accelerated graphics and the ability to rotate an image without using another library was attractive to me. I have zero thoughts of ever going back; SFML may not have the same time and mass of released product but it's clearly the better choice for my needs.