Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML Roadmap  (Read 6645 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9558
    • View Profile
    • development blog
    • Email
SFML Roadmap
« on: August 22, 2018, 04:52:22 pm »
I'd like to discuss the next few steps for SFML's development. I've worded it as if things are already decided, but in fact it's all up for discussion.

Let's start with the big elephant in the room: SFML 3


The bad news: It's impossible to integrate all the changes we have promised, discussed or wished for over the past years.
The amount of potential API changes and redesigns is too great to fit into one version of SFML.

The good news: It has become clearer over the past few years, that a lot of people have adapted the "new" C++ standards and are looking for APIs that do support modern C++ (e.g. move-semantics), but also don't feel particual motivated to contribute to "old" C++ code bases like SFML.


SFML 3 will first and foremost focus on introducing the C++17 standard to the SFML code base and to get rid of some baggage.
Additional API changes or redesigns have second priority on the list.

The overall goal is to accept that major version updates don't require massive library evolutions on the scale of barely achievable, but that breaking changes should be able to happen more frequently and within a manageable scope.
This also implies that we'll actively try to avoid dragging a major version on for many years, which has the the effect, that SFML 3 will end up rather short-lived compared to SFML 2.

Here's a rough roadmap what the goal is in the near future:

SFML 2.6 (see GitHub Project for details)
  • Scan codes
  • Required bug fixes
  • Small championed contributions

SFML 3

Priority 1

Priority 2
  • Hot API discussion points (TBD)
  • (Setup for multiple rendering backends)

Backports

We're generally open to backporting critical bug fixes to SFML 2, but it will be decided on a case-by-case basis and the focus should really be in moving forward.

Summary

The current roadmap moves SFML 3 from an infinitely far away horizon to the next version after SFML 2.6. Major versions don't require massive API evolutions, but it simply indicates a breaking change.

I'm interested in hearing what people think of this proposal, so let the discussion begin!
Keep in mind though, that the point of the discussion here, isn't necessarily about a single item on the list, but it should be more on the whole perspective change.
« Last Edit: May 26, 2020, 11:32:42 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Rosme

  • Full Member
  • ***
  • Posts: 167
  • Proud member of the shoe club
    • View Profile
    • Code-Concept
Re: SFML Roadmap
« Reply #1 on: August 22, 2018, 05:12:39 pm »
Good idea this thread, thanks eXpl0it3r.

My first question is why C++14 for SFML 3.0? C++17 is already standard and is relatively well supported at this moment by every major compiler (according to this page). By the time SFML 3.0 will come out, it will definitely be supported.

Considering how many people seems to ask for filesystem support(and possibily other features), supporting C++17 directly solves that kind of problem, instead of having SFML implementing, only to deprecate it not long after (std::thread vs sf::thread comes to my mind about this). I would expect sf::Thread to be altogether removed anyway from SFML 3.0.

As for the setup for backends, I think it could be very interesting to discuss the possibility of doing such thing. Could also help to port it to more esoteric platform (Xone, PS4, Switch, etc.). I'm all for that, although I understand the work to do something like this can be quite huge.

Finally, while it's nice to add all the things mentions in the list to SFML 2.6, why not start focusing on SFML 3.0 directly for some of those? Scan codes are well advanced that it makes sense, but the rest could probably be more part of SFML 3.0 development directly, making the release of that version earlier than expected, which can only be appreciated.
GitHub
Code Concept
Twitter
Rosme on IRC/Discord

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9558
    • View Profile
    • development blog
    • Email
Re: SFML Roadmap
« Reply #2 on: August 22, 2018, 05:26:56 pm »
My first question is why C++14 for SFML 3.0? C++17 is already standard and is relatively well supported at this moment by every major compiler (according to this page). By the time SFML 3.0 will come out, it will definitely be supported.
Support and adoption are two separate things, but I generally agree that C++17 would provide some additional possibilities. I'd like to see the original C++ Standard discussion to be picked up and continued in its dedicated thread.

As for the setup for backends, I think it could be very interesting to discuss the possibility of doing such thing. Could also help to port it to more esoteric platform (Xone, PS4, Switch, etc.). I'm all for that, although I understand the work to do something like this can be quite huge.
It's certainly a discussion to be had and also check on a technical level what could be done.

Finally, while it's nice to add all the things mentions in the list to SFML 2.6, why not start focusing on SFML 3.0 directly for some of those? Scan codes are well advanced that it makes sense, but the rest could probably be more part of SFML 3.0 development directly, making the release of that version earlier than expected, which can only be appreciated.
There are already many things near completion for SFML 2.6 - if you check the GitHub Project you see that a lot of things are already in review/testing state or at least WIP.
Plus as I said the focus of SFML 3 should be to introduce C++14, clean up some baggage, but it shouldn't be focused on building many new features.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
Re: SFML Roadmap
« Reply #3 on: August 28, 2018, 12:11:30 pm »
Would it be ok to consider switching to using a dependency management tool for that version?
I'm thinking mainly about solving the issue of having binary dependencies inside the extlibs directory.

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9558
    • View Profile
    • development blog
    • Email
Re: SFML Roadmap
« Reply #4 on: August 28, 2018, 12:34:24 pm »
In some endless discussion quite a while back it was decided to move the dependencies into its own repository, but in the end we never did it.

At this point no dependency manager has been well established in the C++ community, as such I don't think we should require one or the other flavor. However I think if we could do it transparently with CMake while you're building, it might be something to think about.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
Re: SFML Roadmap
« Reply #5 on: August 28, 2018, 02:26:58 pm »
Indeed at least separating them would help.

Using CMake apparently would work with recent versions but I didnt try (last time I used ExternalDependency module it failed quite spectacularly for my use case but it was a very complex use case). I know they made efforts in this direction but it's only available in last version(s).

I think at least separating the dependencies and listing the package names and versions somewhere in the root directory would be a good first step for the future of this project's dependenies management.
I guess I long as it's easy for beginner (one command to get everything), it should be fine.

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9558
    • View Profile
    • development blog
    • Email
Re: SFML Roadmap
« Reply #6 on: May 26, 2020, 11:50:33 pm »
I updated the initial post with more recent information and further reduced the scope of SFML 2.6.

Additionally, I have been slowly making progress on the Scancode topic so we can close the last, big remaining feature for SFML 2.6.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6222
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML Roadmap
« Reply #7 on: June 18, 2020, 11:06:41 pm »
[Edit] Now that I think about it, this might as well be its own topic. Feel free to split, if you want to keep this thread focused on the high-level roadmap, without going into detail about C++ related API changes.



Maybe we should start discussing the bigger API changes, especially those that break existing code.
I'm just brainstorming here, so all I write is neither complete nor definitive.

Here's a good overview over new library and language features for all C++ standards.

Error Handling
It would be nice if resources could be returned from factories (named constructors), such as:
sf::Texture tex = sf::Texture::loadFromFile(...);
sf::Image img = sf::Image::loadFromMemory(...);

It would need to be discussed what to do in the error case.
  • Exceptions: Nice to use in the happy path, but can be forgotten. Would require exception hierarchy and error discrimination/display mechanism. Requires exception safety everywhere.
  • std::optional<T> -- Can be empty for failure, but there's no way to convey the error.
  • std::variant<T, E> -- Either the type or an error. Like Rust's Result, but very unidiomatic to use in C++.
  • sf::Result<T> or sf::Result<T, E> -- a simplified version of the above, tailored to SFML. Could have syntax sugar like * dereference.

Major removed APIs
Main candidate I see is sf::Thread.
With it come sf::ThreadLocal and sf::ThreadLocalPtr.

It can be discussed whether sf::Time is necessary given std::chrono, but the latter is very generic and can be overwhelming for the small amount of functionality that SFML needs. Interop (conversion from/to) should definitely be provided though.


Filesystem and path
C++17 Filesystem could benefit both public API and implementation.
If it's too tedious to construct strings to be used in place of std::filesystem::path, convenience overloads for sf::String or const char* can be offered.



Ownership and smart pointers
I can't think of a vast number of places where SFML would benefit from smart pointers, but I could imagine that std::unique_ptr and std::shared_ptr could clarify ownership semantics, when the library does not simply "borrow" (reference to) a user-created object, but (partially) own it.

std::unique_ptr in particular is a good abstraction boundary, when pointers to abstract base classes, such as sf::Drawable or sf::Shape have to be moved (ownership-transferred).

Apart from that, move semantics should be employed in the library, mainly for heavy resources.


New emerged idioms
Smaller things like:
  • passing {x, y} for sf::Vector2 parameters, and subsequently a smaller number of constructors.
  • If there are callback-like classes, instead of having an abstract base class with 1 method, we could use std::function. SFML doesn't use that a lot though.
  • std::byte instead of char/void pointers.
  • enum struct
  • Lambda expressions mostly to simplify the implementation. As expressions, they have no direct use in the API.
  • Range based for loops
  • [[deprecated]] attribute
  • nullptr everywhere, NULL should no longer be used
  • std::optional for parameters and return types
  • override, = default, = delete, and if absolutely needed final

Out of scope
I think we also have to be careful what not to include. In particular, we should not have the mindset "this feature is new, so we have to use it", but rather evaluate on a case-to-case basis, if a new C++ language/library feature actually fits in the scope.

Some things I'm thinking of that should be used with care:
  • Type inference. auto is nice for iterators, but using it for ints and vectors may easily make code less readable. Same for inferred return types -- apart from readability and increased compile time, they can also introduce subtle bugs/breaking changes if a return expression changes type by accident.
  • Template metaprogramming. Variadic templates, folding expressions, variable templates, and all the dark magic around it. If it allows something to be used much easier, why not, but it shouldn't be the primary API design tool  ;)
  • Uniform initialization. This is the biggest misnomer and in my opinion one of the worst additions to the language. Instead of making anything uniform, now we're left with 4 (!!) syntaxes to initialize a variable, and new ambiguities (std::vector<int>{2, 3}) are introduced. A strict convention which syntaxes to use would solve this problem.
  • constexpr and compile-time computations. Those are almost always optimizations, and thus should have low priority compared to more important features. We need to keep in mind that adding the keyword to a majority of the public API also has a readability/usability cost, possibly for a small number of users truly benefitting. It's different for cases where it's easy to add and can significantly improve performance in the general case.
« Last Edit: June 18, 2020, 11:29:53 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

unlight

  • Newbie
  • *
  • Posts: 32
    • View Profile
    • Email
Re: SFML Roadmap
« Reply #8 on: June 20, 2020, 02:14:54 am »
This is a really good conversation starter Nexus! I have some thoughts in response..

Error Handling
I don't like the idea of having resources constructed through factory methods. Once we get move semantics implemented, you could implement your own factory methods that handle errors in what ever way you like. Forcing an error handling method would be an opinionated debate with no right or wrong answers.

Major removed APIs
I agree that sf::Thread has no place anymore, but totally support keeping sf::Time for the reduced verbosity. We could add an std::chrono::duration operator to the Time class so that it works natively with std::thread::sleep functions.


Ownership and smart pointers
I like the idea of using std::unique_ptr for handling object lifetimes inside SFML classes, but personally would prefer if SFML never forced the user to create a smart pointer to interact with the library. This is just personal preference, it would be good to hear what others thought.

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6222
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML Roadmap
« Reply #9 on: June 21, 2020, 01:04:51 pm »
Error Handling
I don't like the idea of having resources constructed through factory methods. Once we get move semantics implemented, you could implement your own factory methods that handle errors in what ever way you like. Forcing an error handling method would be an opinionated debate with no right or wrong answers.
The library still has to provide this functionality. "Opinionated" in this sense mostly means "consistent" and "that's the recommended way of doing it".

Currently, this API is
sf::Texture texture;
if (!texture.loadFromFile(...))
{
    // error handling
}
and this is equally opinionated, but has several technical drawbacks: easy to forget checking the return type, no const variables, no way to get error message/code, unclear semantics when re-loading (and failing), dealing with invalid (unloaded) states, etc.

Of course it can be discussed if this would remain the best API for SFML 3, but keep in mind that the original reason to do it like this was because SFML doesn't use exceptions, so constructors cannot fail.

Constructors on the other hand are not a good idea, as they cannot specify the source (file, memory, stream...), and this would need to be dispatched solely based on parameter types. There would already be conflicts now, e.g. with sf::Shader.

Hence the suggested named constructor idiom (factory) -- it's an established idiom and shines especially in combination with move semantics.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

 

anything