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.
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…