Greater than 20 years later, we’re nonetheless studying new and engaging particulars in regards to the legendary Valve FPS, Half-Life 2. Right now, we’re listening to a narrative type former Valve designer Tom Forsyth a couple of game-breaking bug found in 2013 that seemingly time-traveled and contaminated the unique model of the sport.
I perceive that is quite a bit to soak up, so let’s unpack this genuinely entrancing case of technological happenstance. As extensively detailed on Forsyth’s Mastodon, Forsyth and Valve programmer Joe Ludwig have been engaged on porting Half-Life 2 to the Oculus Rift VR headset, and Forsyth encountered a bug very early within the sport that locked him out of a room and thus away from the crucial path. There was no technique to go ahead, which was bizarre sufficient, however what made it weirder was the truth that nobody might keep in mind encountering the bug within the unique sport. Forsyth even watched movies of the opening scene the place he was encountering the bug, and it wasn’t there.
Clearly, essentially the most pressing concern on the time was simply getting the bug fastened earlier than the sport was to be shipped on Oculus Rift, however including to the frenzy was the truth that Valve gave the impression to be coping with a time-traveling glitch. It did not exist earlier than, and now it did. “How can this presumably be? At this level individuals are freaking out – this is not a traditional bug – it seems to have traveled backwards in time and contaminated the unique!” mentioned Forsyth.
Finally, the builders have been in a position to determine the supply of the bug: a guard who was within the now inaccessible room was standing too near the door, and his toe was colliding with the door because it swung open and inflicting it to swing again right into a closed state. Now that the problem had been found, the repair was “simple” even when it “took plenty of work to seek out as a result of folks needed to mud off outdated reminiscences of how the debugging instruments labored, and many others.”
Nonetheless, the thriller lingered. How within the title of Gabe Newell did this bug from 2013 handle to seek out its means in then-nine-year-old code? And moreover, why was the soldier’s toe not stopping the door from opening in 2004? Or in any of the following years till the bug was found?
“However why did this EVER work? The guard’s toe was in the way in which within the unique model as effectively. As I say, we went again in time and compiled the unique as-shipped supply code – and the bug occurred there as effectively. It is at all times been there. Why did not the door slam closed once more? How did this ever ship within the first place?”
Nicely, fortunately, there’s a solution to this riveting thriller: “good outdated floating level,” per Forsyth. I’ll let an precise sport designer do the speaking for this half, however basically, it is not the sport code that was the issue, it was the {hardware} that was instructing the precision of the sport’s physics, and because of pure coincidence, that precision allowed the door to swing open on {hardware} it was initially constructed for, however not on the 2013 package Valve was utilizing to check the sport.
“Half Life 2 was initially shipped in 2004, and though the SSE instruction set existed, it wasn’t but ubiquitous, so most of HL2 was compiled to make use of the older 8087 or x87 maths instruction set,” mentioned Forsyth. “That has a wacky grab-bag of precisions – some issues are 32-bit, some are 64-bit, some are 80-bit, and precisely which precision you get through which bits of code is considerably arcane.
“However ten years later in 2013, SSE had been normal in all x86 CPUs for some time – the OS relied on it being there, so you possibly can depend on it. So after all by default the compilers use it – in truth you must exit of your technique to make them emit the outdated (barely slower) x87 code. SSE makes use of a way more well-defined precision of both 32 or 64 bit in line with what the code asks for – it is far more predictable.”
Nicely, what that 32 or 64-bit precision was asking for, apparently, was a guard’s foot that would not give technique to a door colliding with it. Within the unique x87 code, there was simply the correct amount of friction constructed into the guard’s boot to permit it to pivot precisely sufficient for the door to swing previous it and open correctly, however the newer SSE had “an entire bunch of tiny precisions” that have been “very barely completely different, and a mixture of the friction on the ground and the mass of the objects means the guard nonetheless rotates from the collision, however now he rotates very barely much less far.
“So on the subsequent body of simulation, his toe remains to be in the way in which of the door,” mentioned Forsyth. “The door is not allowed to only go by his toe, so it does the one different choice – it bounces again. I feel by default it is set to take action fully elastically, so the door bounces again with precisely the velocity it got here in at, slams shut, and locks once more. And also you’re caught.”
Meaning, amazingly, the bug had existed within the sport all the time. The guard was at all times standing too near the door, however as a result of the compiler within the unique construct defaulted to an older floating-point precision, the sport’s physics have been ever-so-slightly completely different to what you’d see on a more recent compiler, and that tiny little bit of discrepancy meant the distinction between a game-crucial door opening and never opening.
“And there you’ve gotten it,” Forsyth concluded. “The 2 greatest bug-farms in gamedev – doorways and floating level – contrived to make a easy NPC placement bug into fairly the time-travelling palaver.”
