Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If I pause with P and then go into the Retroarch menu with F1,the game is automatically unpaused and muted and if I press P again in that menu nothing happens #11776

Closed
ghost opened this issue Dec 29, 2020 · 4 comments · Fixed by #14618

Comments

@ghost
Copy link

ghost commented Dec 29, 2020

Description

So if I pause and then go into the Retroarch Menu,it's suddenly unpaused and the game is muted and I don't want that,I just want it paused until I unpause it manually.

Steps to reproduce the bug

Press P and F1 in a game

Bisect Results

Since I installed Retroarch,some weeks ago

Version/Commit

  • RetroArch:1.9.0-1

Environment information

  • OS:Manjaro Kde
@briaguya-ai
Copy link

briaguya-ai commented Feb 5, 2022

RetroArch/retroarch.cfg

Lines 692 to 694 in be650a7

# If disabled, the libretro core will keep running in the background when we
# are in the menu.
# menu_pause_libretro = false

core_paused = settings->bools.menu_pause_libretro;

looks like this logic makes it so having menu_pause_libretro set to false will lead to games unpausing when opening the menu

@briaguya-ai
Copy link

briaguya-ai commented Feb 6, 2022

after setting some breakpoints (and running into issues) i've been unable to figure out where the cores are getting unpaused

seems like there might be something here?

RetroArch/runloop.c

Lines 7390 to 7400 in 412c798

#ifdef HAVE_MENU
#ifdef HAVE_NETWORKING
bool menu_pause_libretro = settings->bools.menu_pause_libretro &&
netplay_driver_ctl(RARCH_NETPLAY_CTL_ALLOW_PAUSE, NULL);
#else
bool menu_pause_libretro = settings->bools.menu_pause_libretro;
#endif
bool core_paused = runloop_st->paused || (menu_pause_libretro && menu_state_get_ptr()->alive);
#else
bool core_paused = runloop_st->paused;
#endif

setup

  • pause core when menu open set to false
  • pause when lose focus set to false

repro steps

  • press "p" to pause core
  • press "f1" to bring up menu

current behavior

  • core is unpaused when menu is opened

expected behavior

  • core stays paused

@briaguya-ai
Copy link

asked on discord, this has been explored before

there was a fix suggested here

diff --git a/runloop.c b/runloop.c
index ead689e0b5..2f281c29d4 100644
--- a/runloop.c
+++ b/runloop.c
@@ -6312,7 +6312,7 @@ static enum runloop_state_enum runloop_check_state(
       {
          BIT256_CLEAR_ALL(current_bits);
          if (runloop_paused)
-            BIT256_SET(current_bits, RARCH_PAUSE_TOGGLE);
+            video_driver_cached_frame();
       }
    }
 #endif
@@ -6711,7 +6711,8 @@ static enum runloop_state_enum runloop_check_state(
          bool menu_pause_libretro    = settings->bools.menu_pause_libretro;
          bool libretro_running       = !menu_pause_libretro
             && runloop_is_inited
-            && (runloop_st->current_core_type != CORE_TYPE_DUMMY);
+            && (runloop_st->current_core_type != CORE_TYPE_DUMMY)
+            && !runloop_st->paused;
 
          if (menu)
          {

RetroArch/runloop.c

Lines 6730 to 6732 in 412c798

bool libretro_running = !menu_pause_libretro
&& runloop_is_inited
&& (runloop_st->current_core_type != CORE_TYPE_DUMMY);

after adding the && !runloop_st->paused from the patch locally the core stays paused when entering the menu, but it still unpauses when leaving the menu

not sure if unpausing when leaving the menu should be rolled into this issue or spun out into a separate one

@briaguya-ai
Copy link

briaguya-ai commented Feb 6, 2022

cthulhu mentioned that a && !runloop_st->paused check could be added here

if (libretro_running)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant