Shouldn’t the second instance have fixed audio stutters in all cores?
It fixes audio buffer discontinuties caused by improper save/load state, not performance issues that cause framerate to drop below 60FPS.
It’s with 2nd instance enabled and not using the analog stick.
I was playing Adventures of little Ralph, with 3 frames read ahead using your exe of the c++ version.
It was running fine most of the time as long as I wasn’t mashing buttons.
Now read ahead 1 frame is slower than 60fps with the C rewrite submission.
Quite a big difference.
Can you please have a look at Nestopia?; it still stutters in all configurations.
Can’t reproduce any issues with Nestopia. Hope this doesn’t mean that non-msvc builds are broken…
I can confirm the sound problem in Nestopia, with 1 or 2 instances.
Perhaps the 2nd instance option isn’t working?
I don’t see a message in the log saying it loaded another core like before?
Also Pce_fast sound isn’t skipping like before when using only 1 instance.
Confirming mingw builds are borked… fixing it…
Thanks everything works fine like before!
Psx is ok again.
And I realised the PCE thing was a different issue that already got fixed before, I mixed up things.
I tried the run ahead feature (using Windows buildbot version) with the px68k core, but it seems to do nothing at all with this core, pauze+k step frame stays at same frames of lag also. Is it supposed to work with this core? I tried Nemesis 90 Kai and Galaga 88.
(Same buildbot version with Snes9x and run ahead works fine, so it seems px68k core specific.)
Possibilities:
- If it encounters any errors when saving or loading state, the feature is silently disabled.
- Cores which bypass the usual video frame callback and instead use the graphics API directly will still output all video frames, and run at half speed
Px68k doesn’t support save states atm.
I’m not sure if it’s in the source code?
BlueMsx is one were the save states code exist and could be used for RA.
I’ve sent in some pull requests for the Snes9x cores (2005, 2010, Main) now which will speed up the runahead feature dramatically. Uses Fast Savestates, disables rendering when video frames will get discarded, and if using a secondary core, disables audio DSP emulation on that. Maybe in a couple days or so, they’ll show up in the nightlies.
Some of the Snes9x builds I’ve posted here already preview the fast savestate feature.
edit: pull requests were added in, wait for the nightlies tomorrow.
1 Like
The px68k doesn’t support save states indeed. Maybe it can be detected for cores that have no save state support, such that the run ahead feature gets disabled in the frame throttle menu?
Would be great if the save states in the BlueMSX core could be hooked up, but apparently it’s not so easy: https://github.com/libretro/blueMSX-libretro/issues/14
New snes9x is fast, great work (around 500fps in smw at 2 frames/2 instances on i5-3570k). 
1 Like
how much was it suppose to be without runahead? on my crappy dual core it already runs at or about 500 fps without runahead, and 230+/- on runahead 2frames/2instance.
870fps without runahead in smw snes9x mainline, gl driver, cpu @4Ghz.
You could be limited by a shader.
What does the “use second instance” option mean?
Some cores don’t have clean audio after loading state, so Use Second Instance literally makes a second copy of the core so the secondary core can do all the load states. Then the primary core can run all the audio without ever loading state.
So glad to see this in RetroArch nightlies! I’m shocked and thrilled it made its way to mainline so quickly
I did a slow-mo test comparison of Super Mario Bros with a real NES vs. Run-Ahead on a CRT.
With Run-Ahead set to 1 frame, Mario now jumps on the very next frame! 
See the comparison video here:
We’re living in the future! Thank you @Dwedit!
3 Likes