News for hackers. Stuff that matters.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by anthk on Sunday April 19, 2026 @04:18AM (#47822664)
Quake needs a FPU; if that was true it would run on a 486 SX.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by Silphendio on Sunday April 19, 2026 @04:44AM (#47822794)
You're right, I must have gotten that mixed up. Sorry.

I guess floats are still mostly deterministic if you use the exact same machine code on every PC.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by mackman on Sunday April 19, 2026 @09:47AM (#47824286)
One of the hardest determinism bugs I had to solve on the PlayStation three was that the PPU and the SPU actually used a different instruction set and had a different internal floating point register size. We had a multi threaded physics simulation, and during instant replay, we had to ensure that the job scheduler sent the exact same work to the correct cores or we got back subtly different floating point values, which of course, immediately caused major divergences.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by 12_throw_away on Sunday April 19, 2026 @02:45PM (#47826575)
> I guess floats are still mostly deterministic if you use the exact same machine code on every PC.

Nope, they are not. Part of the problem is that "mostly deterministic" is a synonym for "non-deterministic".

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by kbolino on Sunday April 19, 2026 @04:30PM (#47827414)
Floating-point non-determinism issues usually come from one of these sources:

- Inconsistent use of floating-point precision, which can arise surprisingly easily if e.g. you had optional hardware acceleration support, but didn't truncate the intermediate results after every operation to match the smaller precision of the software version and other platforms.

- Treating floating-point arithmetic as associative, whether at the compiler level, the network level, or even the code level. Common violations here include: changing compiler optimization flags between versions (or similar effects from compiler bugs/changes), not annotating network messages or individual events with strictly consistent sequence numbers, and assuming it's safe to "batch" or "accumulate" deltas before applying them.

- Relying on hardware-accelerated trigonometric etc. functions, which are implemented slightly differently from FPU to FPU, since these, unlike basic arithmetic, are not strictly specified by IEEE. There are many reasons for them to vary, too, like: which argument ranges should be closest to correct, should a lookup table be used to save time or avoided to save space, after how many approximation iterations should the computation stop, etc.