Software engineering, music, and general geekery

Remote control bug on first level of LEGO Batman

I bought “LEGO Batman: The Videogame” for PC today (it was going cheap on Steam!). In the first level, I got stuck for a while because of an odd bug. You’re supposed to remote control a little green car, but for some reason it wouldn’t always move.

In summary, the fix which worked for me was to enable Vertical Sync in the game’s graphics settings. More details below.

Problem description

You reach this point during the very first level of the game, just after Robin has got his Technology Suit. What should happen is you access the green tech panel, and you’ll immediately have complete control of the little car. It should move around at a pretty decent speed using the same controls as you’d use for walking around as the characters. You’re supposed to drive it down a small ramp and inside a building where you use it to hit some switches.

I found that I could turn the car OK, but at first it wouldn’t move at all, or would only crawl extremely slowly. After a while, it suddenly started moving. However, it got stuck at the ramp inside the building.

Speculation

Being a programmer myself, I can’t help but speculate what would cause this. The fact that it seems affected by V-sync makes me suspect it could be related to framerate compensation.

For anybody who’s not familiar, Vertical Sync (or v-sync for short) is where the graphics rendering is synchronised with the monitor’s update rate. This means the graphics card waits until the monitor has finished displayed on frame before it starts outputting the next one. Without it, you can end up with visual artefacts called screen tearing (see the Wikipedia article for more info).

Every game will have a main loop in the code, and each time round it will update the game a little more, performing any necessary calculations for movement and animation etc. The speed at which this runs (i.e. the frequency) is very important. The longer it takes to do a single iteration, the further everything in the game will have moved. It’s unfortunately not always predictable though. Depending on what’s happening, the main loop may take longer to complete on some iterations than on others. This means variations in the timing need to be accounted for to make it look like everything moves and responds in a consistent way.

V-sync can affect the timing of the loop because it restricts how frequently the rendering can be done (and rendering is often directly coupled to the main loop). My guess is that the remote control vehicle’s speed is incorrectly tied to the update rate, and without v-sync it thinks the loop timing is going extremely fast. Maybe there’s an incorrect multiplier or a value is being accidentally floored/truncated somewhere. Whatever the case, this would mean it only updates its position by a tiny fraction on each iteration, resulting in very slow apparent movement. Perhaps enabling v-sync makes the update rate consistent enough to avoid the issue.

That’s all wild speculation though so the cause could be something entirely different. Software bugs are rarely simple!