Range: Only use the snapped value if it is different enough from the entered value

[aaronfranke]

Fixes #109838 (not a regression fix this time, this PR is actually an improvement over what Godot has ever had before)

@jan-kapoli commented (but deleted their comment?) asking why we are snapping at all. Well, the reason why is because this is the behavior of Range. However, that still raises a good point. If the value is already good, we shouldn't need to snap it. This PR checks if the value is approximately equal to the snapped value, and uses the original value. This now works correctly even for values and step sizes down to 1e-7:

Snapping will still occur if the value is different enough. For example, with a step size of 0.0000001, if you enter 0.000000101, this gets converted to 9.999999999994822e-08 instead of 0.0000001, but 0.0000001 gets preserved as the closest possible float to 0.0000001 (and therefore serialized as 1e-7).

The behavior in this PR may be slightly worse if you don't trust the user's input, allowing the value to be up to 1e-14 away from the snapped value rather than force-snapping to within 1e-15 or 1e-16 of the best value. However, I think this is a very minor problem (only slightly worse than the imprecision double already provides), and has the benefit that if you do trust the user's input and expect that the value the user entered is probably already good, this helps.

[jan-kapoli]

Sorry, I deleted my question because I felt it was not the place for general questions about Godot's behaviour. I just didn't want to spam the issue. 😅

[KoBeWi]

How does it fix the issue? I see the same behavior when I follow the steps.

[akien-mga]

How does it fix the issue? I see the same behavior when I follow the steps.

Poke @aaronfranke

[aaronfranke]

@KoBeWi was correct, it wasn't working right in all cases, and the problem was due to the relative tolerance as he pointed out.

Since we are using fixed-precision (R128), the tolerance would go lower than where the fixed-precision float "bottoms out". Changing this to a fixed value instead of a relative one seems to work in all cases now.

MRP: Bug.zip

Video of the fix compared to 4.5.1-stable:

oh_snap.mp4

[KoBeWi]

Tested it with the MRP again and it still doesn't fix the original one. idk if the issue is expected to be fixable though.
The new MRP behaves the same with and without this PR, I guess except the serialization changes seen in your video.

Can't say how much useful and expected is this fix, as I'm not familiar with precision-related problems.