Game Dev

There is a game dev track at CppCon, and has been for the last couple of years. Unfortunately there aren’t many game devs that actually go to CppCon, which I think is a real shame. This was the game dev track this year:

I tried my best to make it to all of the game dev talks this year, but unfortunately I did miss a couple. Below are my thoughts on the talks that I did attend.

Zero Cost Scripting Languages for Game Engines with C++26 Static Reflection

The general idea is that AngelScript compiles to bytecode, and Koen is using a mixture of C++26 reflection and C++ #embed to process that bytecode at compile time into an executable function that can be executed at compile time or at runtime. Essentially you can turn any bytecode into C++ code, at compile time.

Why is this useful? The insight is that unless you have a game where players can write their own logic as part of the game (e.g. like Media Molecule’s Dreams), then the game’s scripts never change. If the scripts never change, then why pay the cost of loading them from disk, interpreting the bytecode, and executing them in a big switch-case? So in the case of iterative development, your scripts can be interpreted and executed at runtime, like normal. But at the point of creating your release binary, you can take the final scripts and actually compile them into your C++ binary, as C++.

What does this get you? There is no bytecode to interpret. There is no switch-case to decide how to execute that bytecode. What you have is some compiled instructions that will be executed like native code one after the other. So it is going to be a lot faster to execute. You will also likely get some benefits from the fact that you have effectively turned your bytecode into C++ code. The C++ optimizer is fully aware of the scripts that you want to execute. It can therefore optimize your scripts because they are now C++ code. How fantastic is that!

Koen has made his project public on GitHub here https://github.com/samynk/ToaVM. It seems like he didn’t stop at AngelScript and also has a Java bytecode implementation too. https://github.com/samynk/ToaVM/tree/main/lifter/libs/angelscript is the interesting part of the project to examine.

It is probably worth noting that reflection is probably not entirely required to implement this library, BUT it makes the code a hell of a lot more readable than the alternative version using variadic template metaprogramming! Koen has also been quite upfront with the downsides to this method here https://github.com/samynk/ToaVM/blob/main/docs/TRADEOFFS.md. Obviously compile times would be one of the downsides here… But it certainly is a cool idea that might be worth it in some future projects.

Inside a Small Game Engine: An Architecture tour in modern C++

This was a really fun talk from Elias Farhan who is a game dev teacher at a Swiss University. The talk was about taking his Switch game which was made in Unity, and seeing if he could get it to run faster by bringing it to his own custom game engine.

He went through the general parts of a game engine, and how certain parts of the C++ language and standard library can help model those parts. He talked a decent amount about new containers in the standard library like std::inplace_vector, std::flat_map, and std::hive, and also proposed containers like std::fixed_string. One of the more interesting points that Elias made about std::hive was that it isn’t entirely useful for ECS like structures because it does not support generational indices (indices that are composed of a generation number, and the index). And because of this you might still want to fall back on your own skip field data structure that does have that. Sounds like a proposal waiting to happen to me!

Elias also had a section on the general architecture of a renderer. He talked about what a shader is, how you can group them into pipelines, how you can compose pipelines with resources to make materials, and how you can construct draw commands from materials and meshes.

As the whole point of this talk was about performance, there was a great section on performance testing and optimizations. He described the concept of having “fly through maps” which is something we also have in Sea of Thieves, and how they are great for automating performance captures. Then he talked about two fairly fundamental rendering optimizations. Backface culling, and frustum culling.

Other topics covered in this talk were task graphs, asset loading, compression/decompression algorithms, scene hierarchies and ECS. While talking about ECS, he did also describe a system that sounded VERY like UE5’s Subsystems. He called these hybrid systems where you can have your OOP structure, but still get the speed of an ECS.

Turbocharging Native Code Performance: Compiler Optimizations, Profile Guided Optimizations and Beyond

This was a talk given by Eric Brumer from the MSVC team. I’ve grown to like Eric’s presenting style. There is an element of joy that is very clear in the two talks I have seen him give now.

The crux of this talk was to chat about the different parts of CPU hardware (logic units, SIMD registers, instruction cache etc etc etc), and how optimizers will try and optimize your code for each of those parts. Eric shared something that he is calling “Eric’s Corollary”.

“All sufficiently optimized code is memory-bound”

This makes a lot of sense. Memory is by far the slowest part of any regular program… if you ignore disk reads, or other kinds of I/O.

The next part of the talk was basically going through some select parts of this blog C++ Performance Improvements in MSVC Build Tools v14.51 - C++ Team Blog.

The rest of the talk was all about profile guided optimization (PGO). Specifically Sample-based Profile Guided Optimization (SPGO). He took us through how it works. How it is much easier to work with in comparison to regular PGO. And how much performance we could expect from using it. He did note that Photoshop got a 20% improvement in Windows builds with the use of SPGO which I thought was quite interesting and definitely made it sound like something I should try in some of my projects.

In Pursuit of a 6000 FPS Game Boy emulator

This talk is a sequel to From C+ to C++: Modernizing a GameBoy Emulator - Tom Tesch - CppCon 2025. The last half was all about the optimizations he made to his Game Boy emulator to get it to run super fast.

Among those optimizations were:

1. Link Time Optimization
2. Use a big switch-case -> a hash map of opcode to function pointer might look fancy, but it is very slow in comparison to just a big switch-case
3. Multi-threading
4. And many more that I did not write notes fast enough for.

I also quite liked this talk because I made it on to a slide :)

You can find Tom’s emulator here Tom Tesch / gameboy-core · GitLab