Posts by TomF@mastodon.gamedev.place
(DIR) Post #B0U3fkKdgDI1ZXG4Qq by TomF@mastodon.gamedev.place
2025-11-21T21:50:00Z
0 likes, 0 repeats
What is meant to happen is a guard (spoiler alert - it's actually Barney in disguise) bangs on a door, the door opens, he says "get in", and then the game waits for you to enter the room before the script proceeds.But in this case the door sort of rattled, but didn't open, and then locked shut again. So you can't get in the room, and the gate closed behind you, so you can't go do anything else. The guard waits forever, pointing at the locked door, and you're stuck.
(DIR) Post #B0U3fs8Wf8LzmHeVf6 by TomF@mastodon.gamedev.place
2025-11-21T21:50:15Z
0 likes, 0 repeats
I checked a video online, wondering if my memory was faulty - nope, the door's meant to open automatically, and you walk in. https://www.youtube.com/watch?v=y_3vMUOayyc&t=215s (at 3:40). But... now it doesn't!
(DIR) Post #B0U3fzsVsYIZmwDpoW by TomF@mastodon.gamedev.place
2025-11-21T21:50:53Z
0 likes, 0 repeats
Oh dear. We can't ship this. I get some other folks, including some folks who worked on HL2 originally, and yep - it's broken. And it's broken when you're not in VR either - so it's not something Joe and I broke. But nobody knows why - none of the relevant code has changed.
(DIR) Post #B0U3g80FffF4zFu7zE by TomF@mastodon.gamedev.place
2025-11-21T21:51:15Z
1 likes, 0 repeats
Someone even goes back in the source history and compiles the original game as it shipped - nope, that original version is also broken. How can this possibly be? At this point people are freaking out - this isn't a normal bug - it appears to have traveled backwards in time and infected the original!
(DIR) Post #B0U3gFXpdDGKNQfXnc by TomF@mastodon.gamedev.place
2025-11-21T21:51:27Z
0 likes, 0 repeats
After about a day remembering how to use the debugging and replay tools, someone smart (sorry, I don't remember who) figured out what was going wrong.
(DIR) Post #B0U3gN5lZRZ9mhbFAG by TomF@mastodon.gamedev.place
2025-11-21T21:51:53Z
0 likes, 0 repeats
If you watch the video, when the door unlocks and then opens, there's a second guard standing inside the room to the left of the opening door. That guard is actually standing very slightly too close - the very corner of his bounding box intersects the door's path as it opens. So what's happening is the door starts to open, slightly nudges into the guard's toe, bounces back, closes, and then automatically locks. And because there's no script to deal with this and re-open the door, you're stuck.
(DIR) Post #B0U3gUnculoFglAs08 by TomF@mastodon.gamedev.place
2025-11-21T21:52:46Z
2 likes, 2 repeats
Once we'd figured this out, the fix was simple - move the guard back about a millimeter. Easy. But it took a lot of work to find because people had to dust off old memories of how the debugging tools worked, etc.
(DIR) Post #B0U3gcTiMgdRVJv54i by TomF@mastodon.gamedev.place
2025-11-21T21:53:05Z
0 likes, 0 repeats
OK cool now we can ship the game phew. But why did this EVER work? The guard's toe was in the way in the original version as well. As I say, we went back in time and compiled the original as-shipped source code - and the bug happened there as well. It's always been there. Why didn't the door slam closed again? How did this ever ship in the first place?
(DIR) Post #B0U3gkNyxsns1rIcFc by TomF@mastodon.gamedev.place
2025-11-21T21:53:49Z
1 likes, 0 repeats
So this kicked off an even longer bug-hunt. The answer was (as with so many of my stories) good old floating point. Half Life 2 was originally shipped in 2004, and although the SSE instruction set existed, it wasn't yet ubiquitous, so most of HL2 was compiled to use the older 8087 or x87 maths instruction set. That has a wacky grab-bag of precisions - some things are 32-bit, some are 64-bit, some are 80-bit, and exactly which precision you get in which bits of code is somewhat arcane.
(DIR) Post #B0U3gruqy4FxNpjSxU by TomF@mastodon.gamedev.place
2025-11-21T21:54:13Z
0 likes, 0 repeats
But ten years later in 2013, SSE had been standard in all x86 CPUs for a while - the OS depended on it being there, so you could rely on it. So of course by default the compilers use it - in fact you have to go out of your way to make them emit the old (slightly slower) x87 code. SSE uses a much more well-defined precision of either 32 or 64 bit according to what the code asks for - it's much more predictable.
(DIR) Post #B0U3gzI9Xq3MG7gfkO by TomF@mastodon.gamedev.place
2025-11-21T21:54:46Z
0 likes, 0 repeats
So problem solved, right? 80 bits of precision means the collision didn't happen, but in 32 bits of precision it does, and that's your problem, more bits better, QED, right? Well not quite.The guard's toe overlaps in both cases - a few millimeters is still significantly larger than ANY of the possible precisions. In both the SSE and x87 versions, the door hits the guard's toe. So far, both agree.
(DIR) Post #B0U3h7Z6mgMxv1gKHo by TomF@mastodon.gamedev.place
2025-11-21T21:55:22Z
0 likes, 0 repeats
This collision is actually properly modelled - a big innovation of HL2 was the extensive use of a real physics engine. The door and the guard are both physical objects, both have momentum, they impart an impulse on each other, and although the door hinge is frictionless, the guard's boots have some amount of friction with the floor.
(DIR) Post #B0U3hFf4gNtZ1qXChE by TomF@mastodon.gamedev.place
2025-11-21T21:55:54Z
1 likes, 0 repeats
On both versions, the door has just enough momentum to rotate the guard very slightly. The guard's friction on the floor is not quite enough to oppose this, and he rotates a tiny fraction of a degree. On the x87 version, this tiny rotation is enough to move his toe out of the way, the collision is resolved, and the door continues to swing open. All is well.
(DIR) Post #B0U3hNVRW4wbMI5cnI by TomF@mastodon.gamedev.place
2025-11-21T21:56:11Z
0 likes, 0 repeats
But on the SSE version, a whole bunch of tiny precisions are very slightly different, and a combination of the friction on the floor and the mass of the objects means the guard still rotates from the collision, but now he rotates very slightly less far.
(DIR) Post #B0U3hV6vF85EwYg9gW by TomF@mastodon.gamedev.place
2025-11-21T21:56:34Z
0 likes, 0 repeats
So on the next frame of simulation, his toe is still in the way of the door. The door isn't allowed to just pass through his toe, so it does the only other option - it bounces back. I think by default it's set to do so completely elastically, so the door bounces back with exactly the speed it came in at, slams shut, and locks again. And you're stuck.
(DIR) Post #B0U3hdAPI3clvgN3E8 by TomF@mastodon.gamedev.place
2025-11-21T21:57:25Z
0 likes, 0 repeats
And that's why the bug went "back in time" - because yes it's the old code, but we were using a newer compiler with new default settings. In the original build, the compiler defaulted to x87, but in the newer compilers the default is SSE. It's not that one is "better" - the fundamental bug is that the guard was too close to the door, and that had always been there. But in the original the problem "self corrected" and so was never spotted, whereas in the newer compile it became a showstopper.
(DIR) Post #B0U3hkWdvmZQkfpPMG by TomF@mastodon.gamedev.place
2025-11-21T21:58:06Z
2 likes, 0 repeats
And there you have it. The two biggest bug-farms in gamedev - doors and floating point - contrived to make a simple NPC placement bug into quite the time-travelling palaver. /end
(DIR) Post #B1EJ1krW76rsGLcj4q by TomF@mastodon.gamedev.place
2025-12-14T05:44:11Z
0 likes, 0 repeats
@futurebird Have you introduced them to that dread villain DOCTOR OCTOTHORPE yet?Fun fact: the * character was also named a "sextile" in the same paper. Commitment to the bit.
(DIR) Post #B2bkLYokUB3z9dDELA by TomF@mastodon.gamedev.place
2026-01-24T10:41:17Z
1 likes, 0 repeats
@lukhash Ah, but I WAS there! So in an act of wanton pedantry, I just want to point out that:Wipeout: 1995PSX launch: 1994Back to the Future: 1985DMC-12: 1981:-)
(DIR) Post #B2htJ3SjsDnDBN6RKS by TomF@mastodon.gamedev.place
2026-01-27T09:31:23Z
0 likes, 1 repeats
Just off to bed and wondered why the neighbor's motion-activated lights were blazing. Looked closer and saw... a deer's arse. Yup, that'll do it.