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.
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.
My input method was an Xbox 360 wireless controller. (Full system specs are below.)
A little research shows that this is quite a common problem. Simply enabling Vertical Sync apparently didn’t work for some people, so I suspect there may be other settings which must be set.
Here are screenshots showing my in-game Graphics Settings and Effects Settings (which can be accessed from the game’s Pause menu):
With these settings, the problem seemed to be resolved. Vertical Sync was the only change I made.
I’m fairly sure we’ll never see an official patch for this. Just in case anybody’s trying to research the problem further though, here are my system specs:
OS: Windows 10 Home, 64-bit
CPU: AMD Phentom II X4 955, 3.21 GHz
RAM: 8 GB
GPU: Nvidia GeForce GTX 970 (Gigabyte G1 Gaming Edition)
GPU driver version: 358.50
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!