Adjust AnimatedSprite.frame value assignment behavior to improve integration with AnimationPlayer

[exhaust-pipe]

AnimatedSprite2D/3D is so great — it allows multiple textures in a single node, and makes it easy to set up animations and frame sequences.
However, its built-in animation playback is relatively simple, so I tried using AnimationPlayer instead to control its animations.
This seemed like a perfect complementary solution, but in practice I encountered the following issue.

Let’s say I create a simple linear sprite animation that plays from frame 0 to frame 10 over 1 second. The most intuitive way to do this in an AnimationPlayer continuous track is to set two keyframes:
Keyframe 1: at 0.0s, frame = 0
Keyframe 2: at 1.0s, frame = 10
Intuitively, the frame value should linearly progress from 0 to 10 over the course of one second.
However, AnimationPlayer seems using floating-point interpolation between integer keyframes, and when that float value is applied to the integer property AnimatedSprite.frame, the engine rounds the value by default.
This leads to unexpected timing issues:

• 0.00s → 0.05s: float value from 0.0 to 0.5 → rounded to 0 (half frame duration lost)
• 0.05s → 0.15s: float value from 0.5 to 1.5 → rounded to 1
• ...
• 0.85s → 0.95s: float value from 8.5 to 9.5 → rounded to 9
• 0.95s → 1.00s: float value from 9.5 to 10.0 → rounded to 10

Because of rounding, the first frame is displayed for only half of its intended duration, and all subsequent frames appear half a frame too early.
This breaks the linear playback rhythm, which is especially noticeable for short animations or those that need precise synchronization.

Existing workarounds

• Use discrete tracks
  Requires manually keyframing every frame.
  Loses the benefit of AnimatedSprite’s pre-defined frame order.
• Animate a float property and manually cast to int
  Prevents AnimationPlayer from recognizing it as a frame property, so you can’t preview animations directly.
  Can set invalid frame values without triggering an error.
• Double the animation FPS and add an extra still frame at the start (Compensates for the missing first frame duration)
  Loses the simplicity and ease-of-adjustment of continuous tracks.
  Potentially doubles resource usage due to higher FPS.

All of these workarounds reduce the synergy between AnimatedSprite and AnimationPlayer.

If Godot could change how AnimatedSprite.frame handles float assignments — specifically, by truncating instead of rounding — this issue could be solved.

One possible approach (sorry I’m not familiar with Godot’s source code, so this is just an idea) is to add a new exported enum property to AnimatedSprite:

• ROUND: Current behavior, ensures backward compatibility.
• FLOOR: When receiving a float, truncate to the lower integer. This ensures frame N is displayed from N.0 up to just before (N+1).0, matching intuitive linear playback.
• CEIL: Always round up when receiving a float.

This would allow AnimatedSprite and AnimationPlayer to work together much more effectively for animations.