A time-travelling door bug in Half Life 2

Ah, nice story!

This reminds me of another story with FPU involved. I was a game developer once. We were making a game that consistently triggered assertion failures related to FPU calculations, but only on a single PC in the whole office. The game was explicitly setting FPU precision to 32 bits at the start to make all calculations more consistent. However, on that particular PC, there was a fancy hand writing input software that injected its DLL into every process. As you've probably already guessed, that DLL did FPU mode reset to the default in the event handling loop (i.e., main thread). I had to shift FPU mode setting code from process initialization to the event handling loop to be able to deal with the damage that third party DLLs could inflict.

It's a goal of mine to get Valve using Nix. (I hope our in-progress Windows support would make this especially compelling.)

One advantage of this is that it will become very easy to not only build the original source of the game, but also build it with the original toolchain and dependencies, the toolchains for those dependencies, etc. etc., all the way down.

Hopefully something like that at your finger trips would have made finding the root cause of this bug a good bit easier!

This reminds me of an old bug in simdjson - any usage of it breaks std::unordered_map in unrelated parts of the code due to an unintentional modification of FPU flags: https://github.com/simdjson/simdjson/issues/169

>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.

It's been a while since I've played HL2 but this isn't exactly how I remember it. While a lot of things were physics objects I thought the doors would just smoothly rotate towards their target position without any physics at all. You can't bump them shut with another physics object for instance.

> The door and the guard are both physical objects, both have momentum, they impart an impulse on each other

I wonder if the term "impulse" here has any connection to the various impulse commands available in the source engine. I remember using "impulse 101" and causing havok in the opening plaza area. Spawning zombies on the roofs, sending them after the combine, etc.

https://developer.valvesoftware.com/wiki/Impulse

A Valve employee using YouTube Playthroughs [1] to diagnose a bug is hilarious to me. Awesome story.

[1] https://mastodon.gamedev.place/@TomF/115589894339657055

Reminds me of what G-Man said in the opening scene of HL2: "The right man in the wrong place can make all the differences in the world"

>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.

Insanity. The values were just right. Just wow.