Retroarch: Cores that disable runahead don't re-enable it on close content.

[bslenul]

Description

Cores that disable runahead on load don't re-enable it when you close content. The option still shows as enabled but it doesn't seem to work.

Expected behavior

Turn runahead back ON on close content.

Actual behavior

Runahead stays OFF, even if it says it's ON in the Latency menu.

Steps to reproduce the bug

1. Start RA, turn ON runahead with 1 frame.
2. Start Super Mario Bros. NES, press K, hold jump button, press K, Mario should start jumping already.
3. Now start a game with a core that disable runahead (Mupen, ParaLLEl, PX68k, MAME, DOSBox, etc.). You should see the notification "loading state failed, runahead disabled" or something like that.
4. Close Content.
5. Start Super Mario Bros. again, press K, hold jump button, press K... and nothing, press K again and only then Mario will start jumping.
6. You can also restart the core that disabled runahead, you'll see that the notification doesn't appear anymore, since runahead is already disabled.

Bisect Results

Already happening in 1.7.5, so it doesn't seem to be a new thing.

Version/Commit

• RetroArch: 1.8.9 / b267391

Environment information

• OS: Windows 10 and Linux Mint VM.

[Tatsuya79]

In other words:

When run ahead fails, it's forced off until you restart RA completely.

[Ryunam]

Thank you for opening this. I've always wanted to talk about this issue, but never took the initiative to actually open a thread for some reason.

It's easy to reproduce this problem by setting Runahead to ON, then going into the Images tab and "running" one of the screenshots / picture you have in the playlist. This will launch the imageviewer core which does not support Runahead, so it will trigger the message stating that Runahead was forcibly disabled.

At this point, just run any other core / content that supports Runahead and even if the option is set to ON it will not be active in-game. You can verify that Runahead is not enabled at that point by using the P-K frame advance method.

[jdgleaver]

This should solve the problem: https://github.com/libretro/RetroArch/pull/11137 :)

[bslenul]

You're on fire :p Thank you for that fix too! ❤️

There's still a weird behavior with Mupen64Plus-Next and ParaLLEl, but maybe it's the cores fault?:

• I load SMB with Mesen, no issue, runahead works fine.
• I load a N64 game then I get a "Failed to load state. Run-Ahead has been disabled" (only with second instance enabled!).
• Close content and start SMB again, it gives me that same "Failed to load state. Run-Ahead has been disabled" error.

Also the error message is different than the typical "Run-Ahead has been disabled because this core does not support save states." from the other cores.

However it works fine with the other cores I mentioned (PX68k, DOSBox and MAME), now runahead is properly turned back ON after closing content 👍

[jdgleaver]

Oooh - So that looks like a genuine core error: it seems that it really is failing to load the first save state...

Very odd indeed! I can't imagine why... I'll try to investigate once I've got a few other things struck off the TODO list!

[Ryunam]

Interesting thing is that perhaps (might be just wishful thinking on my part) solving that issue described by @bslenul could make Runahead Second Instance work with Mupen and Parallel RDP.

In fact Single Instance does work in terms of basic functionality: you can see that latency frames are being reduced if you activate it while in-game and test it with the frame advance (P -> K) method. It’s just terribly slow to the point of being unusable. But maybe if Second Instance worked...

In the meantime thank you so much @jdgleaver for fixing this!