Performance profiling is essential for game development and real-time applications.

While powerful tools like Tracy or VTune can do the job very well, they often come with unnecessary complexity, integration annoyances, or platform-specific limitations.

What if you just need a dead simple, lightweight, minimal-overhead hierarchical profiler that seamlessly integrates with Dear ImGui? That’s exactly what I built for my CppCon 2025 keynote demo, and this article will explore its design and implementation.

... read more

Here’s an encapsulation challenge that I frequently run into: how to let users iterate over an internal data structure without leaking implementation details, but still giving them full control over the loop?

Implementing a custom iterator type requires significant boilerplate and/or complexity, depending on the underlying data structure.

Coroutines are simple and elegant, but the codegen is atrocious – definitely unsuitable for hot paths.

... read more

In one of my previous articles, I discussed the design and implementation of the batching system in my fork of SFML.

That system works well, but it requires users to manually create a batch, add drawables to it, and then draw the batch onto a render target. While effective, this manual approach begs the question:

Wouldn’t it be nice if drawables were automatically batched, whenever possible?

... read more

I recently released BubbleByte on Steam, my second commercial game built with my fork of SFML.

It’s an incremental/clicker/idle game where – eventually – the player will see thousands upon thousands of particles on screen simultaneously.

Even with a basic AoS (Array of Structures) layout, the game’s performance is great thanks to the draw batching system. However, I began wondering how much performance I might be leaving on the table by not adopting a SoA (Structure of Arrays) layout. Let’s figure that out in this article!

... read more

Welcome back, SFML enthusiasts! This article is a follow-up to my previous deep dive into my fork of SFML.

If you want to know how I managed to draw 500k sf::Sprite objects at over ~60FPS compared to upstream’s ~3FPS, keep on reading!

Here, we’ll explore two new significant features in my fork:

... read more

In November 2021, motivated by a desire to contribute to the growth and modernization of a library close to my heart¹, I joined the SFML team² after volunteering to lead modernization efforts³.

Over the past few years, significant time and resources have been invested in the 3.x branch, targeting C++17 and modernizing both SFML’s implementation and API.

I greatly appreciate the contributions of everyone involved in the project. However, I felt that a different approach would better align with my vision, which is why I decided to create my own fork: VRSFML.

... read more

By now, it should (hopefully) be common knowledge that the term “zero cost abstraction” is a lie. To be fair, it’s more of a misnomer – had the term been “abstraction likely to result in zero runtime overhead after optimizations” then it would have been much more honest, but I can see why that didn’t fly…

Most C++ developers tend to accept the fact that “zero cost abstractions” provide zero runtime overhead only with optimizations enabled, and that they have a negative impact on compilation speed. The same developers tend to believe that the benefits of such abstractions are so valuable that having your program perform poorly in debug mode (i.e. without optimizations enabled) and compile more slowly is worth it.

I used to be one of them.

... read more