I really wanted to blame the Anniversary Update.

Where should have been a glorious, laminar stream of bullets was instead Morse code. The player jerked around the screen, shooting off at unbidden speed to slam into the walls. The game stopped, and when it started again it was broken.

I should back up.

I’m working on a shoot-’em-up. You’ve got a ship, there are enemies, you fly around and you shoot them down. Simple stuff. Less simple is developing the engine the game runs on. See, I’ve never written a game with a variable framerate before.

When your framerate is variable, this means the amount of time your game is simulating between frames is variable. If you assume that the time between frames is fixed, then your code is littered with that assumption. When a program makes an assumption that doesn’t hold true, things break. Sometimes in fun ways, sometimes your old game just won’t run because it was accidentally relying on a bug that’s since been fixed.

Why bother with a variable framerate, then? Because, on a modern machine, be it running Windows, Android, or what have you, to save power, when you tell the OS “alert me in 16 milliseconds”, it’ll alert you in 16ish millis, along with alerting a whole bunch of other things that said “wake me up when this timer ends”. This behavior isn’t going away (and telling the OS to wake you up in 16 ms wasn’t a great way of doing it even when they didn’t batch these). You have to go to extreme measures to get your program to have exact frametimes on a PC, and that was a rabbit hole I didn’t want to go down.

But I thought I had gotten everything taken care of. I thought I had gotten everything to use the actual amount of time the game was simulating instead of assuming. No matter how many frames per second I was delivering to the screen, the game ran at the same speed. Great! What I wanted!

…Right up until the framerate went too low.

And all of a sudden, I had two problems.

I had to fix my game going wonky when it took too long to render a frame, and I had to figure out why it was taking so long to render frames that were no different from the rest. I built in a frametime graph. I asked for help, I threw profilers at my code — I got it to run faster, I fixed it going wonky, but the sudden spikes in frametimes remained. Then, I noticed something weird: the more violently I moved my mouse, the higher my frametimes got. What. When I grabbed a bunch of stuff on the desktop and shook it around, my frametimes shot up. When I closed a window, the frametime graph showed me a big hump.

My game was competing with the window compositor for resources.

There was a spike in the graph every 60th of a second or so when the window compositor, Windows’s DWM, drew the series of textured rectangles that make up the desktop. And my game draws thousands of the damn things. My game was competing with the desktop itself! I scrambled and slapped an Exclusive Fullscreen mode into the game, which takes over drawing the screen from the DWM, and sure enough, the frametime spikes mostly went away — my second monitor needs drawing to too. And when I popped open a window that’s heavy on the DWM? The spikes returned.

Part 2 is going to turn me bald, isn’t it?