search

TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.14k stars 380 forks source link

Turbo seek doesn't render the proper frame #2081

Open RetroEdit opened 4 years ago

RetroEdit commented 4 years ago

More specifically, turbo seek (sometimes? always?) renders the frame that immediately precedes the frame that should be rendered. To verify this, one can turbo seek to a particular frame in a movie and examine the visual appearance, then seek to the frame that precedes it and frame advance, and compare the visual appearance to the visual appearance from turbo seeking directly. In my testing, doing these two operations that should appear identical resulted in two different rendered frames.

I discovered this while resyncing an mGBA BizHawk 2.4 movie to BizHawk 2.4.2. One instance of the emulator had turbo seek enabled, while the other didn't. I noticed that the frames appeared different when seeking to equivalent frames. After experimenting with settings, I discovered that the issue is present in both BizHawk 2.4 and BizHawk 2.4.2.

nattthebear commented 4 years ago

Is this just framedrop from rendering being skipped? I suppose turbo seek could seek to f - 1, then turn off turbo, then advance one.

adelikat commented 4 years ago

The intent was in fact to do exactly that, f - 1, maybe that got broke at some point

RetroEdit commented 4 years ago

I mean, I don't think it's frame drop per se, since it does render a frame earlier than what it should; unless the final frame is "dropped" for some weird reason? Maybe rendering happens too early in the turbo seek code, but should happen later? Seems less hacky than manually advancing one after seeking, especially if a fix could just address the underlying problem (unless it's a complicated fix, I suppose).

RetroEdit commented 1 year ago

Still present in BizHawk 2.8; still seems to render at least one frame behind (maybe multiple?).

This makes Turbo seek annoying to use in conjunction with Auto restore last position, because sometimes the displayed results will be misleading. At first, I thought it was a desync issue.

Sophira commented 4 months ago

I can confirm this still affects 2.9.1.

I did a bit of research on this bug and it looks like the last released version of BizHawk where this worked properly was 2.3.2; releases 2.3.3 onward contain this bug.

It also doesn't always display the frame before the one that should be displayed; it can be anywhere from 0-2 frames before the one that should be rendered. This makes sense since turbo mode apparently force-enables a frameskip of 3, so it sounds like the solution would simply be to make sure that there's no frameskip on the last frame advance.