Profiling without Source code – how I diagnosed Trackmania stuttering
A very common side effect of working as a programmer is the constant frustration of not having source code access to all the software you use. Bugs, problems or missing features in your own work can be frustrating enough — you know you’ll have to address all those issues at some point. But it’s even worse when you experience an issue and don’t have the option to solve it.
A recent example of this for me was playing the game Trackmania (2020) by Ubisoft Nadeo. If you’re not familiar with the game or any of its predecessors, just think of it as a racing game with wacky tracks and absurdly fast cars, which requires very precise and fast inputs.
While I enjoy the game very much, one issue kept cropping up: The game would stutter randomly but repeatedly, with the framerate dropping from around 130 fps to 10 or even 5 fps for short periods of time. At first, I didn’t worry too much about what I assumed were shader compilation stutters, but they persisted, even when I played the same track dozens of times. This would be bad enough in almost any game, but in a quick-reaction game like Trackmania, a spike of just 100 ms could cause the car to travel more than 40 metres between two frames. Getting a gold medal on certain tracks was hard enough, but with those stutters it bordered on the impossible. So, I was willing to put in the effort to figure out what was going on.
Sadly, I’m not a programmer working on Trackmania or have any access to it’s source files, my best shot at fixing the issues was that anyone online had had the same issue and fixed it. Although I found a bunch of passionate players describing similar issues, the proposed solutions were standard recommendations like: “Updating the drivers”, “Verifying steam files”, “Disabling VSync”… we all know the list.
At this point I started wondering if I could figure out the problem on my own? I don’t have a lot of experience with reverse engineering, but performance optimization is my passion. I started up the game alongside Superluminal to profile (you can read more about the program in my optimization toolbox article).
Reading the Matrix
The profiling itself went as smoothly as usual, and the initial results were as expected. One thread seems to handle most of the work: the ‘main thread’ of the game, plus others that handle tasks such as video playback. We will come back to this later. Just by looking at the thread utilization (the red/green diagram), we can already see the repeating pattern of the central update function.
This type of pattern recognition is an important first step. After all, we don’t know anything about the functions besides their usage pattern. Not only do we have no access to the source code, but we also can’t see any function names without access to debug symbols. Superluminal simply displays their memory addresses.
Fortunately, Trackmania is not the only application executing code here. Like most software, it also calls functions in other libraries, such as DirectX and SDL. Debug symbols are available for many of these libraries (Superluminal detects these automatically). In this example, the game is waiting for DirectX 11:
... continue reading