Open muzikbike opened 2 years ago
This is actually not a floating-point issue; it is caused by an integer overflow in calculating the sum of the squares of the two distances (in sampling points, not blocks) from 0,0 (whose square root is then taken to calculate the absolute distance from 0,0), which causes the square root of a negative number to be taken, and since there is no support for imaginary numbers in floating points, the result is NaN. Using a long instead would cause the End to generate without any issues until about 24.296 billion blocks (or 17.179 billion on both axes).
Would this 64-bit breakdown at billions of blocks out have also been the case in 1.9 to 1.13, or was the world generated differently back then such that it wouldn't overflow in the same way even out at that kind of distance?
It seems that in 1.9-1.13 the function simply took the square root of the sum of the squares of two floats (which would not have any problems until 2^64 on one axis or (2^63)*sqrt(2) on both axes). The difference is that the integer values equal to x/8 and z/8 are cast to floats before being squared and added in the square root function in 1.9-1.13, but in 1.14 and above the sum of the squares is actually calculated as an integer and cast to a float inside the square root function.
The bug report for this issue contains a code analysis that could be used for a fix if you can figure it out: https://bugs.mojang.com/browse/MC-159283
Seems it can be fixed similarly to a lot of the float precision issues - by replacing floats with doubles and removing lossy casts where possible.