Fix unstable AnimationTrackEditor snapping value

[TokageItLab]

Fixes #91729, Fixes #92273. Fundamentally, both are due to lack of precision.

• Explanation about Mismatch of snap results between key movement and cursor movement in AnimationTrackEditor  #91729:

0.0333 second cannot be snapped to 1.0 second because the lack of precision; the result of 0.0333 * 30 is 0.9999.

At some point, for timeline current time, even in second mode, it seems snap was to be done by dividing after the FPS conversion by an int value. However, the snap method for moving keyframes was implemented differently, resulting in inconsistent results. Considering the use case, an internal/temporary int conversion seems to make sense.

• Explanation about Godot Changing AnimationPlayer Snap Settings in FPS Mode #92273:

The 60 fps value is actually converted to 0.01666666666667 second and stored in animation as 0.0166667 second. I don't know if this is a change in 4.0 or not, but I suspect it is the reason why it is not a problem in 3.x (it stored 60 fps without converting?). The problem in 4.0 is that after storing the value in .tscn, the inverse is computed.

The problem in 4.0 is that after storing the value in .tscn, the resuld of 1.0 / 0.0166667 is 59.9999 fps, although 1.0 / 0.01666666666667 is 60 fps before storing. This can be solved by reducing the user-specifiable precision when in fps mode. As I mentioned in my comment, considering the format for broadcasting (such as 29.97 fps), I think 2 decimal places are sufficient.

---

By the way, make sure you don't confuse #91729 with #92273. They are different calculations and need to be corrected in different places:

• Mismatch of snap results between key movement and cursor movement in AnimationTrackEditor  #91729
  • This is a problem caused by errors due to the accumulation of decimals and requires a workaround to correct the calculation at the snap.
• Godot Changing AnimationPlayer Snap Settings in FPS Mode #92273
  • This is a problem caused by an error when calculating the inverse of a decimal, and requires a workaround to reduce the overall user-specifiable precision of the fps mode.

[TokageItLab]

KeyTime in fps mode seems to be limited to int by KeyEditor to begin with.

AnimationTrackKeyEditEditor

    if (use_fps) {
        spinner->set_step(1);
        spinner->set_hide_slider(true);
        real_t fps = animation->get_step();
        if (fps > 0) {
            fps = 1.0 / fps;
        }
        spinner->set_value(key_ofs * fps);
    }

Considering this, limiting with int may be fine. Although for broadcast, it may need to be encoded externally, since the second decimal place is defined as a format, but it needs technically more precise (multiplication comes in to add frames for the signal), so it would not be very useful to support decimals here.

[akien-mga]

Thanks!