[HN Gopher] A time-travelling door bug in Half Life 2
___________________________________________________________________
A time-travelling door bug in Half Life 2
Author : AshleysBrain
Score : 276 points
Date : 2025-11-21 22:48 UTC (2 days ago)
(HTM) web link (mastodon.gamedev.place)
(TXT) w3m dump (mastodon.gamedev.place)
| Panzerschrek wrote:
| 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).
| arcfour wrote:
| 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 wrote:
| And IIRC ammo for heavy and health for soldier!
| MBCook wrote:
| I'm surprised to hear the ammo calculation code would use
| floats.
| HaroldCindy wrote:
| 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.
| netsharc wrote:
| Meta: I'm going to make a Twitter clone that bans you if you use
| it as a multi-paragraph blogging platform... god damn !#@#%!!!.
| fragmede wrote:
| 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.
| viraptor wrote:
| Do you actively want the linked thread to not exist? Because
| not having this posting option does not mean it would appear
| anywhere else.
| bathtub365 wrote:
| Here's a link with the thread unrolled onto a single page:
| https://mastoreader.io/?url=https%3A%2F%2Fmastodon.gamedev.p...
| Wowfunhappy wrote:
| 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 wrote:
| 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 wrote:
| There's a great VR mod for Portal 2. Played it all the way
| through. Surprisingly comfortable to play too.
| nasretdinov wrote:
| 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 wrote:
| 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.
| ErroneousBosh wrote:
| 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.
| HelloUsername wrote:
| DOOR STUCK
|
| https://www.youtube.com/watch?v=dBIh06_bmq0
| shellwizard wrote:
| Original version https://www.youtube.com/watch?v=VqB1uoDTdKM
| g7r wrote:
| 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.
| djmips wrote:
| nice detective work. Global FPU state had sure caused a lot of
| headaches.
| zokier wrote:
| I recall that D3D liked poking FPU state too, which of course
| had all sorts of fun results
| Ericson2314 wrote:
| 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!
| zX41ZdbW wrote:
| 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
| why_at wrote:
| >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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-23 23:00 UTC)