SFML 3 - What is your vision?

[Tank]

There really should be a way of managing the requests better. Personally I have the problem that I quickly lose overview in a forum, because current stuff gets mixed with old stuff. And once you have read the threads marked with "New posts!", it's difficult to remember what's still important and what not.

Just like with this thread: One has to go through *all* posts for collecting all the ideas etc. GitHub's issue tracker would work, however then ideas would be mixed with actual issues, which is not an option as well.

I agree to Nexus that a 100% free-form voting would end up in SFML becoming a 2D game engine with a world editor, tons of effects and a class "sf::GameGenerator" -- probably not what this library is intended for. However a mixture might be interesting, i.e. feature requests are made, everybody discusses them, based on arguments it's accepted or declined, and if it's accepted, people might vote for influencing priority/severity (is that what you meant, binary1248?).

[binary1248]

However a mixture might be interesting, i.e. feature requests are made, everybody discusses them, based on arguments it's accepted or declined, and if it's accepted, people might vote for influencing priority/severity (is that what you meant, binary1248?).

This is what I understood when I saw the UE4 roadmap. They took requests into consideration and only put up the ones they thought made sense. Then they let the community decide which ones were most important to them (i.e. should be done first) by enabling voting. Voting only influences the priority already confirmed features get, not what new features are going to be implemented.

[Rosme]

For the voting system, you folks might be interested in UserVoice. Everyone gets a limited amount of vote and you can discuss whatever feature you want.

[Kojay]

Perhaps SFML 3 can feature genuinely modern C++. Currently, the only sense in which this is true is that it is not C, ie it is object-oriented and employs RAII. Other than that, it has little to do with the STL, the Boost libraries or Alexandrescu's book bearing that title.

• sf::Vector is a template but this genericity is mostly wasted as sf::Vector2f is the bread-and-butter point throughout the library. While the case could be made that OpenGL handles floats anyway, a whole host of other classes could fulfill the float-coordinate Point concept.
• Adapting SFML's classes to Boost.Geometry's concepts makes evident that sf::Shape, sf::Sprite and sf::VertexArray are effectively ranges of points - additionally associated with colors and/or a texture. Conceivably, a std::vector<std::complex<float>> could serve just as well.
• sf::Shape::getPoint, sf::VertexArray::operator[] and sf::Image::getPixel are essentially methods of iteration, yet require additional work to apply generic algorithms on them.

That said, these are merely observations and do not indicate whether the library should go down this road. As Stepanov said, go look at people's code. In SFML's case that's almost certainly indie games. Ideally, code from such projects should be scrutinized to abstract data structures and/or algorithms from. New features added through this method are bound to be useful.

[select_this]

Perhaps SFML 3 can feature genuinely modern C++...

Irritating buzzword at the beginning aside (and I'm not blaming you for that ) I concur that scouring other projects for ideas and inspiration could generate interesting discussion. My only reservation is we could end up with a 'wouldn't it be great if...' scenario and the library could become hideously bloated, or even end up accidentally specializing in certain application types / genres.

As for the API and implementation details, anything that simplifies and / or clarifies the API would of course be most welcome. I don't know if the team plan to have an 'anything goes' attitude to breaking the API between versions 2 and 3, though.

[Nexus]

To be honest, I don't think "Modern C++ Design" as explained by Alexandrescu or implementations in the Boost libraries are the best examples of modern productive C++ code. They show the borders of the programming language and what is theoretically possible, but it's not always a good idea to use those techniques in practice.

For a functionality-focused library like SFML (rather than one that provides features for the language itself), these concepts complicate everything. Concepts require code to be written as templates, i.e. forcing definitions in headers, delaying/hiding compile errors, exposing internals and making compile times explode. Concepts make interfaces implicit; one must read the documentation in order to know an API can be used. They abstract from the obvious parts and make APIs less simple to use.

There are cases where this is appropriate, such as Boost libraries that aim to be usable with all sorts of existing code. However, this genericity comes at a high cost. In my personal opinion, various parts of Boost are overengineered beyond hope; Boost.Graph is such an example. Just compare it with LEMON -- another graph library that is still very generic and uses modern C++ code, but it's way simpler to use, exactly because the developers found a reasonable trade-off between genericity and user-friendliness.

[select_this]

That was a point I was going to mention, actually - I would implore to all and sundry that we don't end up with anything resembling Boost and its template hell in any way.

[Laurent]

I would implore to all and sundry that we don't end up with anything resembling Boost and its template hell in any way

Do you really think I would allow such things, after 7 years of efforts to keep SFML clean?

[select_this]

Do you really think I would allow such things, after 7 years of efforts to keep SFML clean?

You're not the only big fish in the pond now . However, from what I've seen the team buy into the same philosophy (as do I). The post was more of an addendum to my previous one about the vagaries of 'modern C++' (ugh, I hate that buzzword so so so much).

EDIT: Bad Darren forgot to remove the nested quote...

[binary1248]

I think we can all agree on the fact that when SFML takes advantage of C++11, it should focus solely on making the developers' lives easier through use of the new language features. I too don't want SFML to become yet another boost-like C++ demo "just because" it is possible. This is also the reason why I tend to stay away from boost as best I can, some of it is useful (shared_ptr, regex, etc.) but most of it is still over-engineered by people who really have nothing productive to do with the language .

[Kojay]

For a functionality-focused library like SFML (rather than one that provides features for the language itself), these concepts complicate everything. Concepts require code to be written as templates, i.e. forcing definitions in headers, delaying/hiding compile errors, exposing internals and making compile times explode. Concepts make interfaces implicit; one must read the documentation in order to know an API can be used. They abstract from the obvious parts and make APIs less simple to use.

These are shortcomings of the language, not a case against generic programming. Concepts are not currently a feature of the language, hence the obscure errors and lack of helpful intellisense. There is a discussion group and eventually they will be included in the standard; they are the cutting edge, whereas oop and RAII are as old as C++ itself.

Cleanliness, the design of specific libraries... not going to argue over such things.  I stated in the previous post what I think is the ideal method to determine new features.

[Nexus]

Concepts are not currently a feature of the language, hence the obscure errors and lack of helpful intellisense.

You're right that these specific issues are mitigated when concepts are integrated as a language feature, but many of the problems I stated will remain as a result of the template-based implementation.

they are the cutting edge, whereas oop and RAII are as old as C++ itself.

Being new doesn't imply meaningful applicability to all code. For example, a lot of C++11 features are only interesting for designers of generic, language-focused libraries. C++ has always been a language with a wide range of paradigms, and most applications make only use of a specific subset.

By the way, while basic RAII has existed since C++98, resource handling has become more powerful with new language features, e.g. move semantics for unique ownership or noexcept for strict exception guarantees.

Anyway, until C++17 it's a long time. It takes even longer until concepts are fully supported on major compilers, and yet longer until they're adopted by the C++ community.

[Ixrec]

sf::Vector is a template but this genericity is mostly wasted as sf::Vector2f is the bread-and-butter point throughout the library. While the case could be made that OpenGL handles floats anyway, a whole host of other classes could fulfill the float-coordinate Point concept.

What exactly do you mean by "wasted"?  Vector2f, Vector2i and Vector2u are used pretty much everywhere in SFML where it would make any sense to do so.  The fact that Vector2f makes sense the most often has more to do with the way graphics work than the way SFML is designed.

More importantly, the Vector2<T> template is such an incredibly simple class that using it and converting to/from it is effortless, so the benefit of replacing it with a "Point concept" seems negligible at best.  We'd still need separate concepts for float, integer and unsigned points anyway, so it wouldn't make things any simpler.

Adapting SFML's classes to Boost.Geometry's concepts makes evident that sf::Shape, sf::Sprite and sf::VertexArray are effectively ranges of points - additionally associated with colors and/or a texture. Conceivably, a std::vector<std::complex<float>> could serve just as well.

sf::Shape::getPoint, sf::VertexArray::operator[] and sf::Image::getPixel are essentially methods of iteration, yet require additional work to apply generic algorithms on them.

SFML already allows you to use an array of sf::Vertex instead of shapes and sprites, which would get you a lot of that genericity.  I can definitely see an argument for making sf::VertexArray behave more like an STL container with proper iterators (especially since it calls itself an array), but for something like sf::Image, sf::Sprite or sf::Shape, it seems like anyone who wants that level of genericity shouldn't be using such high-level abstractions to begin with.

[eXpl0it3r]

I can definitely see an argument for making sf::VertexArray behave more like an STL container with proper iterators (especially since it calls itself an array)

This would be a total waste. sf::VertexArray is nothing else than a std::vector<sf::VertexArray>, adding more std::vector "features" would only lead to useless code duplication. If you want iterators etc. just role your own vector of vertices.

[Ixrec]

This would be a total waste. sf::VertexArray is nothing else than a std::vector<sf::VertexArray>

Not quite.  The main difference is sf::VertexArray is a Drawable so it lets you simply do window.draw(myVertexArray) without worrying about all the render states.

It'd be nice if there was a way to make it so window.draw() could take a std::vector of sf::Vertex, but a complete solution to that minor problem would probably end up resembling one of those over-engineered boost libraries, so it's fine the way it is.

Never mind, that was dumb.