SFML Development Updates
Up until the other week, we had Coverity Scan, a static analysis tool, enabled for SFML, but while this is usually a commercial product, the usability is terrible to the point, where you have to asked, who would spend money to get this?! In addition, we started to get discrepancies in reporting, where I got errors sent to me via email, but when I looked at the details on the Coverity site, those errors weren’t even listed (anymore?), yet, the issue counter on the dashboard displayed more issues than available in the detail page. Long story short, binary1248 replaced Coverity Scan with SonarCloud, which has a pretty UI and reports a lot more issues.
From the SonarCloud reports we already fixed four issues:
<random>, which briefly lead to a discussion about (re-)introducing a random number generator construct
- Make moving Shapes, swapping Textures and swapping VertexBuffers
- Remove unreachable code
- Switch to using Documentation IP ranges in tests, meaning that some IP ranges are reserved for documentation purposes and thus safe to hard-code in our tests
Turns out that
clang-tidy gets quite a bit of a performance boost, when run against unity builds. Not to confuse unity builds with the game engine Unity, it’s a specific build performance improvement, where the source files/translation units are combined into a single one, that way you have less overhead with header resolving and other preprocessing tasks. Not too long ago Vittorio made SFML compatible with unity builds.
So far we had CMake automatically execute our test suite, if you choose to build it. This was barely noticeable, when we had just a few simple tests, but has since started to contribute quite a bit to the overall “build” time, thus we decided to remove the execution itself. If you want to run the SFML tests, you have to explicitly run the
runtests target from now on.
For our testing, binary1248 has blessed us with a Mesa3D software rendering implementation, so we can more consistently execute graphical tests and it opens some more potential benefits.
Painful Code Coverage
Ever since the introduction of the Codecov code coverage reporting, we’ve been running into sporadic failures when uploading the reports. Sometimes it was just one report, sometimes half the builds failed, and we had to re-run the failed jobs, often even multiple times. We hoped, that by utilizing an auth token it would improve the situation, unfortunately it didn’t. After talking to the Codecov maintainers, it seems like they’re intentionally failing some calls, when they hit a rate limit towards GitHub, which essentially leaves us with just one workaround, adding a retry action.
Performance Boost in Detail
You can always tell, when Vittorio is working on optimizing Open Hexagon, as it spills over to either SFML build improvements or SFML performance enhances, which is great, because it’s quite hard to obtain real-world performance profiles.
This time, there seems to have been some slow downs with the
TransientContext and locking around it. For the last part, there’s still an open PR, which hopefully can reduce some redundant locks in the
setUniform hot path.
As discussed some time ago, we might switch back to Catch2, as v3 was released, resolving all performance concerns, and offering some additional features over Doctest.
Someone from the community opened a pull request to provide
std::string_view support on
sf::String further C++17-ing SFML, which I like to see! 😊
Here are some on-going discussions, we always love to hear more opinions on:
- Allow for Limiting (Max & Min) Window Size
sf::Clockshould be renamed to
- Upgrade away from Legacy OpenGL
SFML Games & Projects
Anyone remember Snake on the Nokia 3310? Well this Snake Game is nothing like that, but it’s always the main image I have in my mind, when I think about Snake. The game was posted on the forum and looks quite polished, when I compiled and ran it, I was unfortunately unable to move passed the menu screen, so I didn’t actually get to play it.
This one I somehow missed in the last post, but it’s a Tetris-like game, with the twist that you can pick the kind of “tetrominoes” you get, but not by shape, but by count of blocks. As the source code only contains a Qt Creator project file, I didn’t want to bother implementing a CMake script for now. Here’s a video of the game play instead:
From the same author we got Twini-Golf, which is a remake of TwiniGolf, a 2021 GMTK Game Jam entry. As this game seemed quite intriguing, I quickly put together a CMake script based on the SFML CMake Template and then continued to fix two small bugs, which prevented the game from starting properly. The goal of the game is to get the ball into the hole, but you have a split screen with a different setup on each. The hit on the ball is applied at the same time, strength and direction on either side of the screen, thus making you think a bit more on how best to hit the balls, to keep the overall number of strokes low.
A multi-threaded raytracer using the SFML master branch. It renders one image and ensures that your CPU is fully maximized – I could feel my system struggle a bit. It’s also interesting that Windows’ window manager takes so long to start fully drawing the SFML window, that half the rendering usually has already been drawn.
Not to get in conflict with my SFML Steam Game series, but there’s a new SFML game to be wishlisted on Steam right now: Western Quest
It’s a Western/Steampunk 16-bit JRPG with turn-based combat and some interesting 2.5D graphics. There isn’t a ton of information yet, but looks like a promising game.
Thrasher and I had discussed a few times, about holding a virtual meeting with the SFML Team, to align on various topics and have discussions with a higher bandwidth (audio rather than text) than usual. A date has been fixed for next week and I’m very much looking forward to having some (hopefully) productive discussions.