29-08-2026, 09:28 PM
@schrowd So I've finally tested your code!
I will still need to review the details of the code itself, but much of the needed functionality has been implemented and works well, so great job!
Now, I noticed some issues or limitations that still exist, so I'll discuss those, as well as how we can go forward to get the feature in the official code.
1. Forward mode
Those issues happen in forward mode.
a) Animations don't respect the playback speed. Now "animation" is wide and can be confusing, so let's clarify: if an object is set to change its position relative to the track (like the Black Forest train), that is tied to world time and works fine. But if some parts of the object move relative to others (for example a character clapping), that's the type of animation that doesn't respect world time. This is true both of animations from track objects (easily seen with the monkeys near Cocoa's start) and from the kart's own animation. An easy way to confirm the latter issue is checking the jump animation from the same spot in the same replay at two different speeds, or simply by pausing with a kart that has the animation looping.
b) The current quick UI implementation breaks the standard pause menu if the pause mode has already been activated
c) Playback speed affects the speed at which the pause menu is brought up.
Control for frame-by-frame play (like the E key to advance videos in VLC) would also be useful.
2. Rewinding mode
Rewinding brings some extra difficulties and issues. Kart info (speed, nitro, powerups...) works just fine when rewinding, and objects that are physically moving in the track behave correctly (for example the great gear in Cocoa Temple rotates in the opposite direction when rewinding).
a) Because the kart now moves in the opposite direction, the relative position of particles to the kart becomes wrong. Simply generating new particles from the current kart position and then have the kart move back can't recreate the proper particles state. What makes this all the more tricky is that the correct positions of particles would depend on what happened dozens of frames earlier.
b) The particles generated may also be unrelated to those that ought to be generated for the given kart position. An easy test is on Cocoa Temple's left path, reaching the first ground zipper and then rewinding: the kart will continue generating zipper particles. Interestingly, if you rewind, zipper particles will start appearing before the kart reaches the ground zipper's location, so some relevant info appears to be stored, it just will also create particles when it shouldn't.
Your commit message also mentions a limitation with regards to the lap counter. I'm thinking that this one may simply be handled by also having the replay store the lap value instead of trying to compute it live.
From a UI perspective, there are some other limitations with the rewinding mode, but those don't really matter for the correctness of the underlying replay mode.
3. Merging the code
Some of the issues can probably be resolved now, other may be addressed later.
Since it is already in a functional state, I think we could already move towards merging relevant code, it doesn't need to be immediately perfect.
I would suggest you submit a PR to the BalanceSTK2 branch with first just the forward mode.
The current UI is more practical than pretty, but it works just fine for testing and an initial implementation, that's always easy to tweak later if the underlying system works. So it's fine having only it for the PR.
One tweak I would like compared to the current version is getting rid of the checkbox to enable replay controls, and enabling replay control automatically in watch-only mode. It simplifies the code and the UI, and replay controls are useful enough that it makes sense for them to be on by default.
Then, when it's merged, a 2nd PR with the rewinding support. It will be easier to validate the code that way.
Fixes to the various issues I found in my testing could be part of those two base PRs or separate PRs depending on when the fixes are done and on the complexity of the fixes.
As an aside, the future UI for replays should also include a convenient way to switch between karts, and the time-difference should take into account the currently shown kart. But that's not directly related to the playback speed code.
I will still need to review the details of the code itself, but much of the needed functionality has been implemented and works well, so great job!
Now, I noticed some issues or limitations that still exist, so I'll discuss those, as well as how we can go forward to get the feature in the official code.
1. Forward mode
Those issues happen in forward mode.
a) Animations don't respect the playback speed. Now "animation" is wide and can be confusing, so let's clarify: if an object is set to change its position relative to the track (like the Black Forest train), that is tied to world time and works fine. But if some parts of the object move relative to others (for example a character clapping), that's the type of animation that doesn't respect world time. This is true both of animations from track objects (easily seen with the monkeys near Cocoa's start) and from the kart's own animation. An easy way to confirm the latter issue is checking the jump animation from the same spot in the same replay at two different speeds, or simply by pausing with a kart that has the animation looping.
b) The current quick UI implementation breaks the standard pause menu if the pause mode has already been activated
c) Playback speed affects the speed at which the pause menu is brought up.
Control for frame-by-frame play (like the E key to advance videos in VLC) would also be useful.
2. Rewinding mode
Rewinding brings some extra difficulties and issues. Kart info (speed, nitro, powerups...) works just fine when rewinding, and objects that are physically moving in the track behave correctly (for example the great gear in Cocoa Temple rotates in the opposite direction when rewinding).
a) Because the kart now moves in the opposite direction, the relative position of particles to the kart becomes wrong. Simply generating new particles from the current kart position and then have the kart move back can't recreate the proper particles state. What makes this all the more tricky is that the correct positions of particles would depend on what happened dozens of frames earlier.
b) The particles generated may also be unrelated to those that ought to be generated for the given kart position. An easy test is on Cocoa Temple's left path, reaching the first ground zipper and then rewinding: the kart will continue generating zipper particles. Interestingly, if you rewind, zipper particles will start appearing before the kart reaches the ground zipper's location, so some relevant info appears to be stored, it just will also create particles when it shouldn't.
Your commit message also mentions a limitation with regards to the lap counter. I'm thinking that this one may simply be handled by also having the replay store the lap value instead of trying to compute it live.
From a UI perspective, there are some other limitations with the rewinding mode, but those don't really matter for the correctness of the underlying replay mode.
3. Merging the code
Some of the issues can probably be resolved now, other may be addressed later.
Since it is already in a functional state, I think we could already move towards merging relevant code, it doesn't need to be immediately perfect.
I would suggest you submit a PR to the BalanceSTK2 branch with first just the forward mode.
The current UI is more practical than pretty, but it works just fine for testing and an initial implementation, that's always easy to tweak later if the underlying system works. So it's fine having only it for the PR.
One tweak I would like compared to the current version is getting rid of the checkbox to enable replay controls, and enabling replay control automatically in watch-only mode. It simplifies the code and the UI, and replay controls are useful enough that it makes sense for them to be on by default.
Then, when it's merged, a 2nd PR with the rewinding support. It will be easier to validate the code that way.
Fixes to the various issues I found in my testing could be part of those two base PRs or separate PRs depending on when the fixes are done and on the complexity of the fixes.
As an aside, the future UI for replays should also include a convenient way to switch between karts, and the time-difference should take into account the currently shown kart. But that's not directly related to the playback speed code.