I Stepped on a Performance Landmine

Today I finally got to the bottom of a strange case of the jitters that Blackshift would often come down with on Windows.

I'd just rewritten my profiling code, because it's time to get serious about performance, and here is the graph it presented me with. Can you see the problem?

If you're not used to reading this sort of chart, it shows how long the game engine spends doing each task for every frame. The Y axis is in milliseconds, and the coloured areas are different tasks. Blackshift runs at 60 frames per second so ideally each frame completes in 1000 / 60 = 16.6ms, which as you can see is usually the case.

As you can see, the graph is dominated by the render task (violet) waiting for vsync, and a rather heavy maroon task which turns out to be...  wait... that can't be right. "Read gamepads"?

I did some research and it turns out [1] [2] that, yes, windows' gamepad routines can take a shocking 8ms just to tell you if any buttons are being pressed. 8ms! If you've got a decent Internet connection you can play Counterstrike with an 8ms ping, which means your inputs are going out of your computer, all the way to s0ulb0y_3edgy420me's house and back quicker than they can get from your joystick, through winmm into Blackshift.

In fact, that's not quite accurate. It turns out, this delay is only incurred if there isn't a gamepad plugged in to your computer. If you actually use one, winmm behaves like a sane library designed by proper people at an actual company and returns its results almost instantaneously.

My solution: If winmm ever reports that there is no gamepad plugged in, simply stop calling joyGetPosEx, which is the devil, until you get a WM_DEVICECHANGE message. You'd think Windows could do something like that internally.

Anyway. Suffice it to say the next Blackshift update will contain Windows performance fixes.