6 ms·

Do games really rely on the rounding behaviors of floats to not break? Seems like there should always be plenty of margin around that. But maybe something does

Do games really rely on the rounding behaviors of floats to not break? Seems like there should always be plenty of margin around that. But maybe something does a loop with these instructions over and over and the error compounds? And wouldn't the solution on x86 be to use the more than double precision floats that are available in the platform? https://en.wikipedia.org/wiki/Extended_precision https://en.wikipedia.org/wiki/Extended_precision

olaulaja 8y ago
We have pieces of code at (gaming related) work that have very tight, and carefully thought out, error bounds (think 4 ULP) and can certainly break if float rounding doesn't work as expected. I'd expect a physics engine to contain plenty of similar code, particularly related to collision detection. Rendering and gameplay logic are probably a bit less picky
kevingadd 8y ago
They do. Slight problems with floating point behavior are the cause of many historical problems with GameCube and Wii games in the Dolphin emulator (which also has to emulate PPC on x86/x64) For a simpler example from personal experience, I had a textbook implementation of triangulation via ear clipping to turn polygons into a list of triangles I could send to the GPU. On Windows it worked great but when I ran it on an XBox 360 it looped infinitely. This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats.
- pedrocr 8y ago
  > This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats. That sounds like a bug though but I guess that's the point. Unless you're bug for bug compatible a reasonable amount of code will fail a significant amount of time...
  - unwind 8y ago
    Performance is often a critical feature in games. Nobody will play a janky game and go "yeah, it's a bit rough but I'm sure the floating-point operations are done sensibly if it were to run under emulation, two console generations in the future". Console games are not like ordinary/business applications where being 15 ms late is almost always better than tying the code to the hardware.
  - toast0 8y ago
    There's not really a bug here. Some algorithms based on floating point numbers require floating point operations to work in certain ways. x86 floating point operates differently than most other floating point systems, in large part because of when it was developed, and that it can't change because it needs to remain compatible with existing code. It would be a bug to release code that required x86 floating point behavior on a non-x86 system, but in this case, it was easily caught during early testing.
  - brucedawson 8y ago
    That may have been a case where the FMA instructions on Xbox 360 gave different results. Or maybe the code was relying on the x86's odd x87 floating-point unit, or maybe the compilers were rearranging the instructions slightly in one of the ways that is legal. Lots of reasons why floating-point math code might behave differently without it being a CPU or compiler bug.
delroth 8y ago
They do. A trivial example is input recording for replays -- if you don't have a very similar FP implementation, the replays will desync: https://www.youtube.com/watch?v=XxGg1TCpYrc https://www.youtube.com/watch?v=XxGg1TCpYrc Collision detection is sometimes also very FP sensitive. See https://www.youtube.com/watch?v=9hwuz2U1JV8 https://www.youtube.com/watch?v=9hwuz2U1JV8 fixed by https://github.com/dolphin-emu/dolphin/pull/390 https://github.com/dolphin-emu/dolphin/pull/390 https://www.youtube.com/watch?v=eEbmrwnYaXs https://www.youtube.com/watch?v=eEbmrwnYaXs has a few more examples we've documented.
jamesgeck0 8y ago
Yep. IIRC, this was why several of the Sonic Adventure ports from Dreamcast has issues where the player character could fall through tiny seams in the floor.
seppel 8y ago
> Do games really rely on the rounding behaviors of floats to not break? Seems like there should always be plenty of margin around that. But maybe something does a loop with these instructions over and over and the error compounds? I remember that in PearPC the sin function of cocoa (IIRC) would crash if the FMA instructions did not provide enough accuracy. It would access a table of precomputed values out of bounds or so.
brucedawson 8y ago
A lack of precision is not the problem. The problem is that at some point the game logic makes a decision such as whether a bullet hit a target, whether a player made a jump, or many others. These decisions sometimes end up right on a cusp, where a single unit in the last place determines the behavior. In a sensitive physics engine these happen more often than you might think. And when the result changes, all future events are impacted. This is crucial for replays, it may be crucial for multiplayer, and it can result in unexpected behavior in ways that you only find when writing an emulator. A slight change in floating-point math may also result in a slightly larger-than-expected number which may then result in a slightly negative number which may result in a NaN (sqrt(-1e39) perhaps) which then results in the poisoning of all future math that uses that number.

olaulaja 8y ago

We have pieces of code at (gaming related) work that have very tight, and carefully thought out, error bounds (think 4 ULP) and can certainly break if float rounding doesn't work as expected. I'd expect a physics engine to contain plenty of similar code, particularly related to collision detection. Rendering and gameplay logic are probably a bit less picky

kevingadd 8y ago

They do. Slight problems with floating point behavior are the cause of many historical problems with GameCube and Wii games in the Dolphin emulator (which also has to emulate PPC on x86/x64) For a simpler example from personal experience, I had a textbook implementation of triangulation via ear clipping to turn polygons into a list of triangles I could send to the GPU. On Windows it worked great but when I ran it on an XBox 360 it looped infinitely. This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats.

pedrocr 8y ago
> This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats. That sounds like a bug though but I guess that's the point. Unless you're bug for bug compatible a reasonable amount of code will fail a significant amount of time...
- unwind 8y ago
  Performance is often a critical feature in games. Nobody will play a janky game and go "yeah, it's a bit rough but I'm sure the floating-point operations are done sensibly if it were to run under emulation, two console generations in the future". Console games are not like ordinary/business applications where being 15 ms late is almost always better than tying the code to the hardware.
- toast0 8y ago
  There's not really a bug here. Some algorithms based on floating point numbers require floating point operations to work in certain ways. x86 floating point operates differently than most other floating point systems, in large part because of when it was developed, and that it can't change because it needs to remain compatible with existing code. It would be a bug to release code that required x86 floating point behavior on a non-x86 system, but in this case, it was easily caught during early testing.
- brucedawson 8y ago
  That may have been a case where the FMA instructions on Xbox 360 gave different results. Or maybe the code was relying on the x86's odd x87 floating-point unit, or maybe the compilers were rearranging the instructions slightly in one of the ways that is legal. Lots of reasons why floating-point math code might behave differently without it being a CPU or compiler bug.

delroth 8y ago

They do. A trivial example is input recording for replays -- if you don't have a very similar FP implementation, the replays will desync: https://www.youtube.com/watch?v=XxGg1TCpYrc https://www.youtube.com/watch?v=XxGg1TCpYrc Collision detection is sometimes also very FP sensitive. See https://www.youtube.com/watch?v=9hwuz2U1JV8 https://www.youtube.com/watch?v=9hwuz2U1JV8 fixed by https://github.com/dolphin-emu/dolphin/pull/390 https://github.com/dolphin-emu/dolphin/pull/390 https://www.youtube.com/watch?v=eEbmrwnYaXs https://www.youtube.com/watch?v=eEbmrwnYaXs has a few more examples we've documented.

jamesgeck0 8y ago

Yep. IIRC, this was why several of the Sonic Adventure ports from Dreamcast has issues where the player character could fall through tiny seams in the floor.

seppel 8y ago

> Do games really rely on the rounding behaviors of floats to not break? Seems like there should always be plenty of margin around that. But maybe something does a loop with these instructions over and over and the error compounds? I remember that in PearPC the sin function of cocoa (IIRC) would crash if the FMA instructions did not provide enough accuracy. It would access a table of precomputed values out of bounds or so.

brucedawson 8y ago

A lack of precision is not the problem. The problem is that at some point the game logic makes a decision such as whether a bullet hit a target, whether a player made a jump, or many others. These decisions sometimes end up right on a cusp, where a single unit in the last place determines the behavior. In a sensitive physics engine these happen more often than you might think. And when the result changes, all future events are impacted. This is crucial for replays, it may be crucial for multiplayer, and it can result in unexpected behavior in ways that you only find when writing an emulator. A slight change in floating-point math may also result in a slightly larger-than-expected number which may then result in a slightly negative number which may result in a NaN (sqrt(-1e39) perhaps) which then results in the poisoning of all future math that uses that number.