Change default AnimatedTexture's fps to 0

[Mickeon]

Closes godotengine/godot-proposals#4742.

Previously it was a somewhat arbitrary 4.0. I can only speculate it was done to show the AnimatedTexture... animate as soon as its frames were added, but the documentation makes full note of the behaviour when fps is set to 0, which is quite a bit more more noteworthy.

[akien-mga]

I'm OK with the change, but I think the documentation is not clear enough about what happens with fps set to 0.

Animation speed in frames per second.

OK.

This value defines the default time interval between two frames of the animation, and thus the overall duration of the animation loop based on the [member frames] property.

That's a bit confusing already because it sounds like the value of fps is the time interval (in seconds?) between two frames. While in fact this time internal is 1.0 / fps (fps of 4 means a time interval of 0.25 between each frame).

A value of 0 means no predefined number of frames per second, the animation will play according to each frame's frame delay (see [method set_frame_delay]).

That's the main problem here because it doesn't say enough. The default frame delay is 0. So with a default fps and a default frame delay of 0, how will the animation play? I assume what's implied here is that the equation for the interval between two frames is 1.0 / frame_count + frame_delay, i.e. that a fps value of 0 is equivalent to an fps value of frame_count.

[Mickeon]

I unironically love to modify the documentation, I'll see what I can do.

[Mickeon]

Pushed and updated that description after thoroughly testing AnimatedTexture myself.

But man, AnimatedTexture's entire description (an entire behaviour) feels... OUTSTANDINGLY antique. I may follow this up... It really feels like the way it works and is described is more complicated than it has any right to be in Godot 4.

[filipworksdev]

A positive fps actually overrides all individually chosen frame delays to an equally distributed value based on the chosen fps. An animation with 2 frames 0.5s and 1.5s will end up something like 2.0s 2.0s when fps is 4. It changes the very nature of your animation.

I think fps should be reworked with a proposal perhaps. It would split it two properties:

• an on/off override that controls if the individually chosen frame delays will be forced to an equally distributed value
• and a float/percent/second/fps value that can stretch/shrink the speed of the entire animation.

[Mickeon]

@filipworksdev See #65188