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

Author Topic: SFML Roadmap  (Read 3084 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9221
    • 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 is that SFML 3 won't be what we have hyped it to be for past years. Simply put, it won't be a refactoring of everything.
The good news is, that cutting down on "change everything" actually brings SFML 3 into a scope again, that can be achieved.

SFML 3 will first and foremost focus on introducing the C++14 standard to the SFML codebase and to get rid of some baggage. Only secondarily will we evaluate API changes.

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 again means, 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)

SFML 3
  • C++14
    • Move semantics
    • NonCopyable
    • unique_ptr
    • ...
  • Deprecation
  • Hot API discussion points (TBD)
  • (Setup for backends)

Backports

This shouldn't be at the center of the discussion, but as the question my arise, I just want to mention it now. We're open to backporting certain bugfixes to SFML 2, but we're also reserving us the rights to decide whether it makes sense or not.

Summary

The current roadmap moves SFML 3 from an infinitely far away horizion 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: October 23, 2018, 10:14:27 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: 150
  • 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: 9221
    • 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: 9221
    • 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.