That's why we are adding scancodes for improved keyboard handling, full customization of blending modes, more types of shader parameters, etc.
That's only completing features you already started.
What he is talking about is the fact that SFML tends to put a limit on what it expects a beginner to game programming to need for their first project. Anything beyond that is deemed (and I'm paraphrasing here) "not the target audience of SFML". One might think that adding more features than a beginner might
initially need might intimidate them a bit, but hiding the true complexity of the matter at hand can only bring you so far. By primarily thinking of beginners you are saying that in order to keep using SFML, they either have to not make any progress at all in terms of development practices, or that once they have gotten the hang of things and completed their first few projects, they can go and use another library that allows them to do more. If that is really what the philosophy of things is (and I really hope it is not) then it is quite sad that a library with so much potential is artificially limiting itself when it does not have to.
Time and again, I have tried digging through old posts of feature requests, here and on the tracker dealing with adding more "enthusiast" features only to get forgotten about, because there wasn't much interest on the side of the community and the initial person who made the suggestion probably left SFML for greener pastures or worked around their problem.
The reason why the feature set needs to be so limited was never really mentioned anywhere. The step from SFML 1.6 to SFML 2 was mainly about the drawable update and API aesthetics, but in terms of actually providing users more to work with to build more complex projects, I didn't really see many additions. SFML 2 has been around for a while already, and there isn't any official or unofficial roadmap for SFML 3.
What eXpl0it3r is suggesting is that SFML consider expanding its target audience in new directions, exposing platform features in a completely optional way. You already showed us that you can do that with sf::Shader by allowing the user to check for support before using it. Why can't more features be implemented like that? If a developer knows they don't want to target machines more than 8 years old then let them decide for themselves.
That is what he means with the definition of "simple". You have to ask yourself, who is it supposed to be simple for? Surely the same thing might not be as simple for one person as it might another... I could probably write a 90% complete shader without having to look anything up on the OpenGL wiki whereas others might find using the sf::Shader class daunting. For example, if you have a class called sf::TransformFeedbackBufferObject does that necessarily mean it will make life for beginners less "simple"? Not really. And people who want to use that feature with its clean interface will rejoice that SFML makes
their lives simple as well.
I think a better definition of the word "simple" would be "easy to use" as opposed to the (in my opinion) current definition of "easy for beginners to understand". If you are a beginner, fine, there is nothing wrong with that, you can leave the more complex stuff for later, but don't limit what others who were here before you can do. Not everybody decided to pick up game programming at the same time, and those who are at it for longer will naturally have other needs than those who just started yesterday.
Now, you might bring up the "do it in X yourself" argument, X being OpenGL, win32, etc. If that is the case, why even bother providing something like sf::Shader in the first place? Obviously it requires knowledge in GLSL and so it can be expected that if the person reads about GLSL they will also get exposed to "normal" OpenGL programming in some form. One could argue that once you need shaders you might as well drop the SFML drawable API in favour of just doing everything yourself in raw OpenGL. Once you need some specific cross-platform feature that is not in SFML but is widely used everywhere, you should roll your own implementation. Is this the right way to go? If you ask me no. SFML can make these otherwise complex and time consuming things "simple" to do for advanced users who need them. And beginners who are looking for a library to stick with for a longer period of time are not shaken by the fact that once they do learn a bit, they lose the advantage that SFML provided them for the first 200 hours of development.
On the pages of many libraries, you often see lists of features that they support. When beginners look for a library, they will probably read through the list of features and decide if it is good for their needs or not. They might not understand or need all of the features, but that is natural. They might not know how to use a feature
yet but maybe it might be something they want to try later on when they have a better understanding of the basics. Promoting a library's primary "feature" as its being easy to learn isn't attractive enough for me at least (and I suspect many beginners who do in fact plan ahead of time). The ones who probably land here the most are those that type "game programming simple" or something like that into Google and expect to be hand-held from start to finish. The ones who know how to compare libraries with each other might even start with something more complex such as Irrlicht or OGRE although they have no prior knowledge. I was one of those people a long time ago, and I eventually ended up using SFML because its API was much much cleaner than all the rest, and I saw potential in the idea that the complex things I had seen in those other libraries could be made simple to do. SFML already succeeds in doing many things in a cleaner, more simple way than other libraries. Window management, input management, audio are some of those things, but what about the rest? There are many things that those libraries do that SFML never tried or even considered doing. Is it because no simple API could be designed for those features? I don't know, but I haven't found any serious long-lasting discussions about any such features.
If a beginner is overwhelmed and just gives up when their auto-complete shows them a list with 1000 entries then I say they should not be your target audience. Trial and error is not the most effective way to learn anyway. Think of SFML like any RPG. In RPGs your character levels up and becomes more powerful over time. They acquire more abilities/spells to choose from every level and more slots to equip them in. Is it a good idea to give a level 1 character 1000 spells to choose from? Probably not, since they haven't gotten the hang of many mechanics. Is it a good idea to limit the level 200 character to the same 10 spells that they had access to at the start of the game? We all know how well that game will do
. SFML currently puts a very low level cap on the character and basically says: "You'll learn how an RPG works here. If you want to play a real RPG go play another game." I don't think veteran RPG players will enjoy this game for a long time, let alone even consider playing it
.
It's not about the amount of things you present, it's about how you present them to your audience.
