Input Lag Compensation to compensate for game's internal lag?



That’s not the case here, I tried to load an x86 core and it gives a different message.

Ok, got it working, it was just missing some redist dll without giving any error message.


Try the new build then…


Thanks! Works fine using SameBoy.

But using fceumm to try Akumajou Densetsu and despite the sound that is now good, it’s jumping around a lot.
Well, in SMB too.

Happens with pce_fast too.

Could be because of autofire in the core or something like that… I tried to remove remap and override but that wasn’t it.
(If I activate the autofire with the hotkey it’s smooth again, probably because that forces to resync regularly?)

Impressive that it can work in mednafen psx, and saturn where it’s more than needed (but needs a really fast cpu).


RE:fceumm dunno if anyone read that PR in fceumm before the merged, but even super mario bros. can still have slight “crackling”, which is more noticeable when you increase sound quality in core options.


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.


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.


That new snes9x PGO build gives me 420fps vs 370 for the previous one.
That’s +50% against snes9x standard build, quite something. :open_mouth:

Thanks for the fix: fceumm and pce_fast work fine now.


Yoshi’s Island rotating screen:
580fps with GPO snes9x.
615fps with standard snes9x.

690fps with GPO snes9x.
720fps with standard snes9x.

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.