Project

General

Profile

Emulator Issues #8718

Frame Advance often unpauses emulation during input recording.

Added by adiffin502 over 6 years ago. Updated over 5 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Hitting the frame advance key while recording input tends to result in the game unpausing, without sound.

  1. Start recording input.
  2. Pause emulation and begin to advance frames.
  3. After a few frame advances, emulation should unpause by itself.

4.0-6820 tested. Can't test any more right now, since the website is down.

History

#1 Updated by JMC4789 over 6 years ago

I don't run into this issue myself, was testing it the other day.

#2 Updated by adiffin502 over 6 years ago

I tried it again, and apparently it only happens when pausing the game using the Frame Advance key, a massive habit of mine.

  1. Start recording input
  2. Press Frame Advance to pause emulation
  3. After a few frame advances, emulation should unpause by itself.

Seems to happen with all revisions tested. If anything, Frame Advance shouldn't work unless emulation is initially paused.

#4 Updated by Fog over 6 years ago

This is a regression from 4.0-5402, when the hotkey functionality changed Wrong.

#5 Updated by JMC4789 over 6 years ago

  • Status changed from New to Accepted
  • Regression set to Yes

#6 Updated by phire about 6 years ago

  • Milestone set to Current

#7 Updated by Armada about 6 years ago

Please test this again with the latest development version.

#8 Updated by Fog about 6 years ago

still an issue as of 4.0-7099

#9 Updated by Fog about 6 years ago

to further comment on this, pressing play and pause repeatedly will also trigger the issue.

#10 Updated by delroth almost 6 years ago

Fog, do you want to own this?

#11 Updated by Fog almost 6 years ago

This seems to be more an issue with how the GUI interacts with the CPU core than just a single frame advance issue. Possibly a race condition?

#12 Updated by Fog almost 6 years ago

Nevertheless, I think the title is misleading because frame advance is probably not the only place this issue occurs, but it's the most obvious place to find these issues.

delroth: This issue is probably better suited for someone with much more intricate knowledge of the GUI and CPU emulation.

#13 Updated by Fog over 5 years ago

This isn't as much of a blocker in comparison to the rest of the blockers, I'd be okay with having it removed from Current milestone.

#14 Updated by delroth over 5 years ago

It's a regression which makes TASing really annoying.

#15 Updated by Fog over 5 years ago

  • Assignee set to Fog

#16 Updated by JMC4789 over 5 years ago

  • Priority changed from Normal to Urgent

Easiest way to reproduce this is to load a fifolog and attempt to pause it. Holy shit is it annoying.

#17 Updated by JosJuice over 5 years ago

  • Priority changed from Urgent to Normal

The Urgent priority is for breaking something everyone uses, not FIFO logs and TASing.

#18 Updated by Fog over 5 years ago

  • Assignee deleted (Fog)

FIFO logs issue is separate from this issue, and it has a PR in place to fix it.

As for this issue, I have nothing.

#19 Updated by Fog over 5 years ago

  • Status changed from Accepted to Fix pending
  • Assignee set to Fog

No wonder I had nothing, 4.0-5402 was not the reason this broke.

The real regression happened with 4.0-6364.

The changes in 6364 have been reverted in PR 3712: https://github.com/dolphin-emu/dolphin/pull/3712

#20 Updated by Fog over 5 years ago

  • Status changed from Fix pending to Accepted
  • Assignee changed from Fog to Sonicadvance1

#21 Updated by Fog over 5 years ago

  • Status changed from Accepted to Fix pending
  • Assignee deleted (Sonicadvance1)

#22 Updated by Fog over 5 years ago

  • Status changed from Fix pending to Work started
  • Assignee set to Fog
  • Priority changed from Normal to High

That PR was completely incorrect in the way of fixing the issue, going to work on a better solution.

#23 Updated by Fog over 5 years ago

  • Status changed from Work started to Fix pending
  • Priority changed from High to Normal

After discussing on IRC, I've re-opened the PR.

#24 Updated by mimimi over 5 years ago

I'm trying to understand what happens here. To me it looks way to obvious:
"Press Frame Advance to pause emulation"
and then press the same button to continue? So Dolphin executes the hotkey 2 times in a row, even if it's just pressed once? That doesn't sound like a race condition with pause/unpause, but an issue with hotkey handling.

#25 Updated by JosJuice over 5 years ago

  • Assignee deleted (Fog)

New PR: https://github.com/dolphin-emu/dolphin/pull/3794

Also, mimimi, that's not how frame advance works. If Dolphin is paused, pressing frame advance is supposed to unpause only for a frame, not permanently.

#26 Updated by Fog over 5 years ago

  • Milestone deleted (Current)

Dropping from Current. Current fix is a huge change before a 5.0 release. I'll be directing TASers away from stable so they don't run into this issue.

#27 Updated by Fog over 5 years ago

  • Status changed from Fix pending to Fixed
  • Milestone set to Current

Also available in: Atom PDF