While playing with the code I found a bug in the Subtract function (I checked the last zip file and it's still present).
Essentially it all boils down to floating point precision: each chunk coordinate is cast to real32 separately and when the integer value has more digits than the maximum number of significant digits of the float number (it should be 7-8 digit if I remember correctly) the difference computed can be 0 even when it is not because the lower digits get lost in the cast.
It was the reason that caused the tiles to be in the same position when the world origin was moved to the center and the chunk coordinate were still unsigned (UINT32_MAX / 2 and UINT32_MAX / 2 + 1 for example were represented by the same real32 number and the difference was 0 instead of 1). On a side note now that the chunk coordinates are int32 and the world origin is 0 the problem will surface only when the world become extremely large.
If the real32 cast is performed on the computed int32 difference the problem goes away (a possible loss of the lower digits can still happen if the difference itself has too many digits but I don't know if it's relevant in this case because unless it's going to change the function is called between chunks that are spatially near each other so the difference is going to be small).
Essentially it all boils down to floating point precision: each chunk coordinate is cast to real32 separately and when the integer value has more digits than the maximum number of significant digits of the float number (it should be 7-8 digit if I remember correctly) the difference computed can be 0 even when it is not because the lower digits get lost in the cast.
It was the reason that caused the tiles to be in the same position when the world origin was moved to the center and the chunk coordinate were still unsigned (UINT32_MAX / 2 and UINT32_MAX / 2 + 1 for example were represented by the same real32 number and the difference was 0 instead of 1). On a side note now that the chunk coordinates are int32 and the world origin is 0 the problem will surface only when the world become extremely large.
If the real32 cast is performed on the computed int32 difference the problem goes away (a possible loss of the lower digits can still happen if the difference itself has too many digits but I don't know if it's relevant in this case because unless it's going to change the function is called between chunks that are spatially near each other so the difference is going to be small).
Yeah, that definitely sounds like a mistake - I will make a note to look at it on the next stream!
- Casey
- Casey