Are you using the second instance of the core feature?
Heās talking about the 1st, Iām using the 2nd method.
im missing something since castlevania still whips 3 frames after (or 4 presses of āKā). is this the new one?
I noticed it can stop working after closing core, launching something else.
Or running a core that didnāt support states perhaps, canāt reproduce now.
no, im running it straight after re-opening retroarch and it doesnt seem to have this feature enabled
Did you activate the options in Settings->Frame Throttle?
I was getting a little discouraged when Snes9x with two frame runahead was running a little slow, so I looked into building Profile-Guided Optimization (PGO) builds.
I successfully made one PGO build, except Visual Studio took HOURS to compile it, and needed to use the 64-bit linker due to running out of RAM. What the hell Microsoft. PGO builds are supposed to take like 5 minutes.
When running on Fast Forward without using any lookahead, the buildbot build runs at about 500FPS, and the PGO build runs at about 580FPS. Nice.
Iām also trying out adding support for letting the Frontend tell the Core when video and audio are suspended, so the emulator doesnāt have to work as hard during those frames. That also seems to work well. 350 FPS with 2 frame lookahead on Fast Forward vs 188FPS.
In order to make a better PGO build, Iād need people to play some SNES games using a slow PGO-Instrumentation (Data Collection) build. I just went through the demo of Mario World, Chrono Trigger, Mario Kart, Mario RPG, and a little gameplay from Yoshiās Island to pick what to optimize, but playing a better selection of games may be better.
Hereās a PGO build of Snes9x.
I also updated the Retroarch Build as well, so it can tell Snes9x that audio and video are suspended and increase performance.
1 Like
ok, found it. Turned ON āRead-Aheadā now input frame lag is reduced, BUT the audio issue when changing to higher sound quality is still there, it is still the same as i described in that PR. turning on āUse 2nd instanceā somehow helps, but Super Mario Bros. is now playing like on a very very bad netplay session as now video also desyncs.
note that im only testing in fceumm currently, and Super Mario Bros, havent checked carts with expansion audio and fds yet.
On a related issue, what are the chances that this can work in linux too, at least for development purposes, as i seldom use windows (only on a āhave toā situation)
Same here with fceumm.
If you push control regularly, like an autofire on button B, then it syncs fine.
Same behaviour with PCE_Fast/SGX.
Using PGO build of Snes9x in Super Mario World with 2 frames read ahead and 2 instances, itās an improvement of 280 vs 370 max fps against the standard snes9x core here (stressing controls with autofires + random directions).
Thereās something weird going on with FCEU. It isnāt checking any input other than Port 0, Device 1, Index 0, ID 13 from the secondary core. Whereas other emulators are checking all inputs from the secondary core as usual.
Edit: Figured it out, wasnāt forwarding the retro_set_controller_port_device command to the secondary core. So FCEU thought nothing was plugged in.
Newer Retroarch Build should fix FCEU.
Edit: New PGO build for Snes9x too, this sucker is FAST. Briefly tried it out, and it was almost as fast as Snes9x 2005.
Edit: Just for kicks, I tried building a PGO version of Snes9x 2005. Linking the PGO build took 3 seconds rather than 3 hours.
2 Likes
That new snes9x PGO build gives me 420fps vs 370 for the previous one.
Thatās +50% against snes9x standard build, quite something. 
Thanks for the fix: fceumm and pce_fast work fine now.
Yoshiās Island rotating screen:
580fps with GPO snes9x.
615fps with standard snes9x.
Gameplay:
690fps with GPO snes9x.
720fps with standard snes9x.
SMW:
1030fps with GPO snes9x.
960fps with standard snes9x.
SuperFX shows slight slowdown with GPO build.
I donāt think this quite matters on a desktop PC.
Same here on Yoshiās Island 575 vs 600fps in the advantage of the standard build.
But thatās without any read ahead option activated at all.
My previous tests were made with āUse 2nd core instanceā, 2 frames read ahead + stressing out controls to make a worst case scenario.
280 vs 220 fps PGO winning, testing Yoshiās Island with these settings in actual gameplay.
I just wanted to quickly chime in and say a big āthank youā to Dwedit and all the parties involved with this new, exciting implementation! This is amazing and I canāt wait until this is stable enough to hopefully be integrated as an option within mainline RetroArch.
Iāll be testing this and report back with any potential findings worth of note.
Yes, I donāt want any C++ code being introduced at all. The more code stays C, the better.
I made a single and sole exception for the Vulkan/Slang stuff but I never really intend to make such an exception again if I can help it. And if it could be helped, I would have gotten rid of that C++ code yesterday. It is nothing but a terrible maintenance and portability hazard.
So, letās please keep this C, and we can both be happy here and we can merge this in speedy fashion.
Also, the C code needs to be C89-compatible. So no variable length arrays, declare variables at the top, no designated initializers, etc.
I donāt know about you guys but I think this is freakinā incredible! Dwedit youāre a mad scientist! Retro Arch is already amazing having only one frame of lag on Windows 7 which I am perfectly happy with but damn, using a second core to look ahead to remove the frames of lag that exist on real hardware make me feel as if I am playing real hardware even on my laggy LCD TV. But beyond that itās just so incredibly cool for you to exploit the shortcomings of the real hardware. Rest assured I will be playing all my SNES games with this feature engaged so I can report any bugs.
āremoved- Itās merged, you can grab a recent nightly.
Compiled from the current PR branch Dwedit sent, rewritten in C.
Same support / compiler as the buildbot.
I notice itās now running at the speed where you force the sync by stressing the controls.
With beetle-psx software, I could play with several frames ahead previously, as long as I wasnāt using the controls too much. Now itās always the worst case: 1 frame ahead stutters.
Not experiencing that, trying out Beetle-PSX with Dragon Warrior 7. With run ahead 1 and no secondary core enabled, itās slow. When secondary core enabled, itās normal speed, when I hit buttons, itās slow again.
Beetle-PSX probably needs some optimization, especially fast save states.
Is this related to variation in the position of the analog stick every frame? That would cause dirty input.