SFML community forums

General => SFML development => Topic started by: eXpl0it3r on August 22, 2018, 04:52:22 pm

Title: SFML Roadmap
Post by: eXpl0it3r on August 22, 2018, 04:52:22 pm
With SFML 2.6.0 finally out the door and SFML 3 development being in full swing, it's time to update the Roadmap planning.

SFML 2.6.1

We have identified and already fixed some build configuration issues and I'm expecting to see further reports over the next couple of weeks/months.
SFML 2.6.1 will only contain "important" bugfixes, with everything else landing on the master branch for SFML 3.

SFML 3

The overall goals have not really changed:

While we had in the past a lot of ideas for SFML 3 (https://en.sfml-dev.org/forums/index.php?topic=15027.0), the current goal isn't to provide decade long massive update of SFML, but really to focus on the C++17 support, clean up and API breaking changes.

Here a few open points, which anyone can help out with!

In the first ever Maintainer Meeting, we've decided to not consider a (major) graphics API overall. This means, we'll not be rewriting or accepting changes to refactor the whole rendering API.


(click to show/hide)
Title: Re: SFML Roadmap
Post by: Rosme 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 (https://en.cppreference.com/w/cpp/compiler_support)). 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.
Title: Re: SFML Roadmap
Post by: eXpl0it3r 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 (https://en.cppreference.com/w/cpp/compiler_support)). 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 (https://en.sfml-dev.org/forums/index.php?topic=21571.0) 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.
Title: Re: SFML Roadmap
Post by: Klaim 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.
Title: Re: SFML Roadmap
Post by: eXpl0it3r 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.
Title: Re: SFML Roadmap
Post by: Klaim 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.
Title: Re: SFML Roadmap
Post by: eXpl0it3r 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 (https://github.com/SFML/SFML/projects/4).

Additionally, I have been slowly making progress on the Scancode topic (https://github.com/SFML/SFML/wiki/SD:-Scancodes) so we can close the last, big remaining feature for SFML 2.6.
Title: Re: SFML Roadmap
Post by: Nexus 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. (https://github.com/AnthonyCalandra/modern-cpp-features)

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.

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: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:
Title: Re: SFML Roadmap
Post by: unlight 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.
Title: Re: SFML Roadmap
Post by: Nexus 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 (https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Shader.php).

Hence the suggested named constructor idiom (factory) -- it's an established idiom and shines especially in combination with move semantics.
Title: Re: SFML Roadmap
Post by: eXpl0it3r on November 30, 2021, 02:59:37 pm
Some update on the current situation.

The scancode feature (https://github.com/SFML/SFML/pull/1235) is very slowly being finalized, it's still planned for SFML 2.6.

As there's a high interest (https://en.sfml-dev.org/forums/index.php?topic=28301.0) in getting the ball rolling for bringing C++17 to SFML and thus also starting off the development for SFML 3.

To achieve both of these goals, we created already a sort of release branch 2.6.x (https://github.com/SFML/SFML/tree/2.6.x) and will start development of SFML 3 on the master branch right now.
Title: Re: SFML Roadmap
Post by: eXpl0it3r on December 03, 2021, 04:37:33 pm
Not sure where to place the best, so I'll just do it here for now.

We want to document breaking changes on the following wiki page: https://github.com/SFML/SFML/wiki/SD:-SFML-3:-Breaking-Changes

This doesn't have to be elaborate in anyway, but I believe it's simpler to collect this information as we go, than try and reconstruct it after the fact.
The goal for me would be to write a sort of upgrade guide before the SFML 3 release.
Title: Re: SFML Roadmap
Post by: KyraDigitalGames on March 30, 2022, 02:24:49 pm
Looks good, but you should definitely plan smaller releases.

It is standard in game development to only use releases and not the master version. So we've been stuck on 2.5.1 for 4 years.
Title: Re: SFML Roadmap
Post by: Nexus on March 31, 2022, 05:36:42 pm
Looks good, but you should definitely plan smaller releases.
Generally I agree, during "stable" times this is the way to go and we have neglected this to some extent.

During a huge breaking change however (SFML 3), many small releases directly conflict with Semver, which is also good industry practice. I know that many libraries don't care about this, and it makes everyone's life harder and is one big reason why dependency management is such a mess in C++ (another reason being lack of standard tooling).

If we had released during the SFML 2->3 period, we would have had two options:
At the end of the day, both groups are faced with several iterations of breaking changes, just to maintain feature parity. Sometimes we might even revert previous changes. I'm not sure this is what we want.

When game developers prefer outdated releases over Git versions due to policies, that's a reasonable strategy when it comes to minimize the number of code adaptations (at the cost of one bigger change taking more time). But it's ultimately their decision, they are free to use an in-development version to benefit from cutting edge changes (at the risk of bugs and API changes). So everyone can choose a trade-off acceptable to them.

TLDR: it's a matter of communication -- I think the current model makes it relatively clear that the Git version is "in flux" while releases are stable.
Title: Re: SFML Roadmap
Post by: MetalCoder on April 21, 2023, 01:18:31 am
I hope its okay if I ask this, but will SFML 2.6 have a C port release? I see that SFML 2.6 is getting very close to being released.
Title: Re: SFML Roadmap
Post by: eXpl0it3r on June 26, 2023, 10:05:12 pm
I've just updated the first message (https://en.sfml-dev.org/forums/index.php?topic=24372.msg164645#msg164645).
Title: Re: SFML Roadmap
Post by: Thrasher on June 28, 2023, 01:32:35 am
I like this updated roadmap. We just merged yet another 2.6.1 fix so please keep using and testing 2.6.0 to find whatever remaining quirks there are so we can get them cleaned up.

When it comes to 3.0.0, I think the C++17-ification changes are almost done. Certainly there are no more big C++17 features to use. The remaining language usage upgrades are minor and/or can be done after 3.0.0 ships if need be.

As for API-breaking changes, those are harder to predict but I'd like to think most API changes are also done although some of the remaining API changes planned are pretty tough to write and test so don't expect them to get completed soon. My personal goal is to tentatively finish all these API breaks by the end of 2023 so we have time to let the API sit in a stable state while the final testing push occurs.

I expect we need on the order of >3 months of a stable API to be certain that what've written can withstand the test of time. I'm not sure where the other maintainers are at, but I'd like to ship 3.0.0 in the first few months of '24, hopefully soon enough to get it shipped into Ubuntu 24 LTS but that may be tough if we can't freeze the API by approximately November of this year.