2024-12-21 marks the date I had the honor of running git tag 3.0.0 on the SFML repository followed by a git push --tags to make it official. SFML 3 has become a reality!
After three years of development, while continuing to fix SFML 2.6 and refocusing many times, we’ve managed to release a new major version of SFML, close to 12 years after SFML 2.
The thing I’m most proud of isn’t any feature that we managed to ship, but that we had 60 contributors of which 41 were new ones. That’s a lot of volunteers to help with SFML 3! It’s awesome to see, that people aren’t just using the library, but that they’re happy to help with building it. My hope is, that we can keep this up for the future!
The Goals
The SFML Roadmap, created somewhen in 2018, called for three goals:
- Upgrading the SFML API for C++17
- Cleaning up redundant and deprecated code
- Adding features as we go along:
- API breaking features only possible at a major version change
- (low priority) Non-API breaking features
Number two was relatively simple to implement, even though there were some disagreements on the usefulness of sf::Clock / sf::Time, but otherwise it wasn’t too hard to cross off all the APIs, that have been marked as deprecated already or have found replacements in the standard library.
The C++17 update was a trickier topic. For one it was hard to focus on, since it was “just” some C++ maintenance, but harder yet, figuring out what features we wanted to adapt. For example, only time will tell if the implemented move semantics was scoped adequately or if we have over or under done it.
We managed to add quite a few useful features, but this was never the main goal. So once we felt the other goals we reached, we drew the line and started finalizing the release. Additionally, I believe we’ve made good attempts at changing the API in ways, that will allow for new features to be added with minor SFML 3 releases.
One goal that we didn’t intentionally plan for at the start, but developed over time, thanks to Thrasher going full-throttle at it, is our test suite. Even though I’ve written about the Test Strategy and with the help of Tank laid the testing foundation with SFML 2.6, I didn’t expect us to manage an 57% code coverage when shipping SFML 3.
The Future
My personal goal is to get SFML 3.1 out this year, but its contents isn’t fully defined yet. We have a few open pull requests already, which I hope to merge, but I’m also very much interested in adding more sf::Text magic such as HarfBuzz support for complex text layouts and maybe some tools for better text alignment. Whether this can all be achieved in the given timeframe remains to be seen.
Looking a bit into the future, it’s crucial that we finally move away from legacy OpenGL. Not being able to support OpenGL ES 2.0 or OpenGL 3 core contexts with the graphics module (e.g. sf::Texture or sf::Shader) has turned away many users and is long overdue for change. This however is clearly something for SFML 4, as trying to support such a change with the current graphics API would be quite tricky, plus I really don’t want another 12 years of a single SFML major version holding back the development of SFML. I’m also hopeful that we can abstract the API in away to give power users access to more low-level constructs, while providing quality of life features such as sprite batching!
Hope to see you somewhere along the ride! 🙂