Refactor AnimationSpeed related stuff #484
Merged
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.
Previously,
AdjustedAnimationSpeed
was computed withinDrawableSentakkiHitObject
,SentakkiHitObjectLifetimeEntry
andLineLifetimeEntry
. Now this calculation is done centrally withinDrawableSentakkiRuleset
, with each of the mentioned above binding to the bindables provided by it, instead of directly to the config values.Since
DrawableRuleset
is guaranteed to be alive during gameplay, we can actually easy recompute the AnimationSpeed every update to compensate for rate-adjusting mods likeModWindUp
orModAdaptiveSpeed
, resulting in the animation speeds being consistent throughout. (LifetimeEntries aren't drawables, so they can't spontaneously update; DHO's aren't always on screen, so they can only update if they are present)Bonus changes
The performance impact of refreshing transforms every frame seems negligible in my basic eyeballing. Profiling shows roughtly 400ms of CPU time over a 4 minute beatmap, which should only apply when using rate adjusting mods.