Handle internal seek on AnimationPlayer to process discrete correctly #94420
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TokageItLab
force-pushed
the
player-seek-internal
branch
from
5f442b0
to
98dbd86
Compare
fire
approved these changes
Jul 22, 2024
|
@fire See ContributorChat's conversation with @QbieShay https://chat.godotengine.org/channel/animation?msg=rRtWMWRL8TBPqWpnt |
|
Thanks! |
This was referenced Aug 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Discrete mode gets the previous key during seek, but when it is playing backwards, it gets the next key in time. This could cause a problem since time is going backwards when stopping, and that is being treated as a reverse playback seek
As for stopping, restarting, the key must be obtained in Exact mode not Nearest mode, just as start playback. It should be treated as an internal seek.
I cannot determine if it is correct behavior of retrieving the previous key when seeking. I believe this has been the old behavior. And I expect it is a hack to process the last key after crossing a key, because in the past it was not possible to get the delta correctly when seeking (I remember I have fixed that at early 4.0). So it may be a behavior that should be fixed now that we are able to get the delta. I will send another PR for about it later if needed.