A time-travelling door bug in Half Life 2
26 comments
·November 21, 2025Ericson2314
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!
why_at
>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.
sigmoid10
You can't move them (apart from the opening and closing animation), but they can move other objects that are in their way. Both need to be physics objects for that to work, even though the door is just kinematic (i.e. it won't react to forces applied to it). Although if I remember correctly, they are not even fully kinematic. I think you could get them stuck halfway closed by cramming something in the door frame that would get the whole thing jammed.
zX41ZdbW
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
Wowfunhappy
Wait, so is that "beta" of Half Life 2 VR a thing I can play? If it is, how did I not know about this, and if not... why not?
I'd also love to play Portal, actually. They say it makes you sick, but to my knowledge I'm immune from VR motion sickness, so worth a try...
aranelsurion
I don’t know about the beta, but there’s an excellent HL2 VR conversion mod you can play today. It feels just right and got me to play HL2 again after all these years.
davepdotorg
There’s a great VR mod for Portal 2. Played it all the way through. Surprisingly comfortable to play too.
HelloUsername
shellwizard
Original version https://www.youtube.com/watch?v=VqB1uoDTdKM
Panzerschrek
It seems to be typical - some calculations break while switching from x87 to SSE. The same happened with TF2 too - it's ammo calculation code worked slightly differently on GNU/Linux build of the game, because it was built with SSE instructions (Windows version still used x87).
MBCook
I’m surprised to hear the ammo calculation code would use floats.
HaroldCindy
I expect this is / was a very common problem for people porting 32-bit game code to newer compilers. I work on a fairly old codebase that forces use of x87 for a handful of code paths that don't work correctly otherwise. GCC will use default to x87 if you do an i386 compile, but will default to SSE for 64-bit builds, so you have to be careful there too.
arcfour
I think the only visible effect from that was the Engineer's metal, giving +40 or +41 from a small box, depending on the server platform (all classes technically do have metal, but the others can't use it).
It was always fun to play on a new server and check what OS it was running that way, too. :-)
stoltzmann
And IIRC ammo for heavy and health for soldier!
nasretdinov
I wonder how on earth stuff like x86->ARM translation works so well if games break even after switching from x87 registers to SSE preserving all the logic otherwise...
toast0
I think x87 fpu is the only 'weird' floating point units left. I think if you stick with 64-bit double precision floats or 32-bit single precision floats, where the registers are also 64 or 32 bits, all the modern stuff behaves the same. x87 is just weird because registers are 80-bits ... the idea was to have more accurate results from more precision, but it ends up weird because if you run out of registers and have to spill to memory, you typically lose precision.
Edit: since this post was second chanced, I can add on that some of the pre-PC consoles have weird floats too. If they had floats at all. Lots of fun for emulation developers. Even fun for contemporaneous game developers... PilotWings on the SNES comes with different revision accelerator chips and the demo only works properly on the early revision chips (but I think? the later revision chips have more accurate math). The PS2 FPU has weirdness around NaN, Infinity, very large numbers, and denormalized numbers. Etc.
pdw
Rosetta uses software emulation for x87 floating point. That's slow, but in practice that doesn't matter much. Mac software never had a reason to use x87 FP, every Intel Mac had at least SSE3 support.
ErroneousBosh
It's probably because you have to have weird precision issues where the numbers are calculated ever so slightly differently, and some other effect like a guard being slightly too close and getting clipped by a door where that difference matters.
I debugged some software synthesizer code a while back (like 20 years or so now I think of it) where a build of it on one platform failed because of a precision bug. I can't remember the details, but there was a lot of "works fine on my machine" type discussion around it. Anyway it relied on a crude simulation of an RC circuit reaching very close to 0 asymptotically to trigger a state change, but on something like 64-bit Intel with a specific processor it never quite made it low enough to trip the comparison because of something to do with not flushing denormals.
From an electronic standpoint, making it simulate "it's high enough" as being about 0.7 and " it's low enough" being about 0.01 was far closer to the instrument they were trying to simulate, and making it massively imprecise like that got it going on everything.
YouAreWRONGtoo
[dead]
netsharc
Meta: I'm going to make a Twitter clone that bans you if you use it as a multi-paragraph blogging platform... god damn !#@#%!!!.
bathtub365
Here’s a link with the thread unrolled onto a single page: https://mastoreader.io/?url=https%3A%2F%2Fmastodon.gamedev.p...
viraptor
Do you actively want the linked thread to not exist? Because not having this posting option does not mean it would appear anywhere else.
fragmede
I'll make one that's the opposite (your post must be at least two paragraphs and an LLM is going to judge your text to make sure it's not lorum Ipsum) if you'll help me get users.
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.