41 weeks in one SFML News? Well it certainly has been a while and I’ll be painting with big brushes here.
SFML 2.6.1
As previously hinted at, we did end up releasing SFML 2.6.1 in November 2023 and have since then accumulated a few more tiny fixes, including just the other day a 13 years old bug, that haven’t yet warranted a new release.
CSFML 2.6.0
The work from SFML 2.6.0 has slowly trickled down to CSFML and we managed to push out CSFML 2.6.0 at the beginning of February 2024, but have found a few missing pieces, which we’ll be delivered as part of CSFML 2.6.1. While we try to be very strict about semantic versioning on an API level for SFML, we can’t really adhere to the same level for CSFML, otherwise we wouldn’t be able to keep the two APIs in sync, when we notice an accidental breakage.
SFML.Net 2.6.0
Going one level deeper, or I guess one level higher, we haven’t managed to publish a new version for SFML.Net. I’d say, mostly because I didn’t invest the time into SFML.Net and/or cleaning up mishaps in CSFML to release CSFML 2.6.1 so that SFML.Net could be fully in sync. The work itself has all been done by community members, which is awesome to see!
CSFML 3.0.0
“Wait, but SFML 3 isn’t even done!”, is what I hear you say, but yes, we’ve started to lay some groundwork for the development of CSFML 3 in parallel to SFML 3, following the same branching model. With some of the C++17 changes in SFML 3, the transfer of those into a C API will be quite interesting and potentially challenging, but we’ll take it one step at a time.
SFML 3.0.0
We have a difference of over 800 commits between SFML 2.6.1 and SFML 3.0.0, of those, around 300 commits have been made in those past 41 weeks, so yes, a lot has been happening. In no particular order, here are a few topics that saw changes made to SFML:
- CI enhancements
- Enhance our GitHub issue templates
- Test suite expansions
- Image
- Texture / RenderTexture / RenderTarget
- Shader
- Text
- Sprite
- Socket / TCP / UDP / Selector / Listener
- Event / Keyboard / Clipboard
- …
- Many clang-tidy fixes
- CMake enhancements
- C++11/14/17 features
- Using
std::filesystem::patheverywhere - Additional move semantics
- More robust memory management for low-level APIs
- Using
- Align API naming for
getNativeHandle - Modernize Android example
- Fix various issues
- Add support for scissor testing
- Add support for stencil testing
- Use scope enums
- Add
sf::Statefor handling fullscreen and floating windows for future expansion - Replace OpenAL with miniaudio
- …
Check out the link above if you want to see everything!
Replacing OpenAL with miniaudio
OpenAL or rather OpenAL-soft, which is an implementation of the OpenAL specification that we’ve been using, has been a blessing for many, many years. It’s very widely supported, in so far that we didn’t have to do anything on “newer” platforms like Android or iOS. Yet, it also has always been a bit of a thorn, as its LGPL licensing put us into the position, where we never provided the option to link OpenAL statically and so people had to deal with a shared library all the times. Especially on Windows, where a lot of developers like to link everything statically, you always had to remember to ship the one DLL as well. Plus it could cause issues, if you used a different version of the OpenAL DLL. And finally, we’d be getting people every few weeks who were asking, how to create a single executable with everything integrated, which we could only answer with disappointment.
This is no longer the case! As of this week, we’ve merged the fine work of binary1248, who kicked out all the OpenAL bits and integrated mit MIT licensed miniaudio library as our new audio backend. The change is very fresh still and I expect us to run into some issues, be it in our implementation or in unexpected ways of how miniaudio handles things.
Either way it’s really exciting to have this merged and see what potential this will hold!
Over 50% Code Coveage!
The test sub-list above is way too short, because Thrasher has been absolutely throwing everything he got at writing tests for SFML and it paid off, because as of two weeks ago, we’ve hit the magic 50% of code covered by tests! 🎉
When I talked about testing with Tank and binary1248 way back in the 2010s, I had my doubts that we would one day get SFML over the 50% code coverage line. I know it’s not all about the number, but this a massive achievement for a library in the C++ and multimedia space!
It’s awesome and while it takes a lot of effort to get all the systems work properly, especially with things like graphics or audio test, I’m looking forward to where this journey will bring us next.
Scissor & Stencile Testing
These two PRs (scissor testing, stencil testing) have been lingering for a long, long time. Maybe the API is not the most elegant, maybe it’s not how Laurent would have implemented it, but I don’t think it makes sense to let this code rot any further in some PRs, just because we couldn’t make a final decision on it. The SFML 3 API is not set in stone yet, so there’s still room in case some users have additional inputs, but I’m perfectly happy to get this added to SFML 3, with the foresight that we can always readjust in SFML 4.
Again, a massive thanks to binary1248 for the endurance and polishing everything up for us.
What’s Next?
It’s hard to not jump into adding more and shiny features onto SFML 3, but as repeated many times, I still believe we should follow the three priorities:
- Modernize for C++17
- API breaking improvements
- Additional features
SFML 3.1 and 3.2 and so on still allow us to add new features, as long as they aren’t API breaking. As such, I really want to focus on getting all the API affecting C++17 work done and stabilize the API as much as possible, so that we can start producing release candidates sooner than later.
SFML.Net 2.6.0 is certainly high on my personal priority list, so we can close the whole 2.6.0 chapter.
Additionally, there’s still a lot of non library work, such as updating the website, creating releases, writing tutorials, writing changelogs, etc. for which we can hopefully also find some simplifications in the near future.