Post #1552889

2025-11-21 21:53 UTC

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.

Replies (3)

@TomF@mastodon.gamedev.place 2025-11-21 21:54

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.

Open ##1552890
@Doomed_Daniel@mastodon.gamedev.place 2025-11-21 21:54

@TomF ha, that was my assumption when reading the prior posts - either fast-math or x87

Open ##1552896
@GabeMoralesVR@mastodon.social 2025-11-22 06:26

@TomF lol it's always floating point precision, isn't it? The recent Sonic 1,2,3 16:9 remakes ditched the old 16.16 fixed point math of the originals for a floating point vector system for collision, and people suddenly say "it's not accurate" when, in fact, it's *more* accurate, just that the original used a ton of hacks and bugs that created bizarre edge cases.

Open ##1552897