4 ms·

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

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.

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.