.NET Framework's x86 JIT, as it turns out, isn't IEE-754 compliant, and doesn't round the 80 bit internal registers back down to 32 bits of precision after operations on floating point numbers. This can cause some operations (like the divisions modified by this patch) to execute with more precision than specified, and as such result in more accurate results than on compliant platforms. Concretely, this means that modern mono builds (which are for example used by the MacOS version of the game), 64 bit .NET Framework versions as well as .NET Core will diverge from .NET Framework, which causes a desync of the 6HC TAS in room 06 (the different AnalogMode.Precise behavior already affects earlier rooms, but it isn't an issue till this room).
In this case, using 64 bit double calculations instead of the 80 bit x87 calculations seem to provide enough precision to ensure both .NET Framework and other platforms arrive at the same result, this issue might affect other places in the code as well though.
.NET Framework's x86 JIT, as it turns out, isn't IEE-754 compliant, and doesn't round the 80 bit internal registers back down to 32 bits of precision after operations on floating point numbers. This can cause some operations (like the divisions modified by this patch) to execute with more precision than specified, and as such result in more accurate results than on compliant platforms. Concretely, this means that modern mono builds (which are for example used by the MacOS version of the game), 64 bit .NET Framework versions as well as .NET Core will diverge from .NET Framework, which causes a desync of the 6HC TAS in room 06 (the different
AnalogMode.Precisebehavior already affects earlier rooms, but it isn't an issue till this room).In this case, using 64 bit double calculations instead of the 80 bit x87 calculations seem to provide enough precision to ensure both .NET Framework and other platforms arrive at the same result, this issue might affect other places in the code as well though.