Snes9x needed a patch called “lagfix” to make the snes9x core have one less frame of input lag, so yes, the selected core can indeed add lag.
Some cores that exhibit an additional frame of lag compared to their stand-alone versions or other faster cores are: all Mame cores, VBAM (next is fine), Picodrive.
Also new higan/nside because how vsync works vs stand-alone method.
1 Like
silentq15 started documenting some here:
That’s correct, such things have no impact on the game’s internal lag, but they do impact your system’s lag, which is stacked on top of the internal lag.
His point is that you can reduce the game’s internal lag to compensate for your system’s lag, so that the total lag is as close to the original hardware as possible.
1 Like
That’s quite true! The ability to adjust towards that ballpark (fathful lag reproduction). Others users want less lag than original hardware, and maximize RunAhead (lag advantage). A user preference.
@Dwedit, 10 times faster savestates? – That’s a very impressive coding optimization job!
1 Like
Hey @Dwedit, I have just tested the updated Beetle PSX core and the improvements are absolutely noticeable! I can now use Secondary Instance smoothly on my system with Hard GPU Sync ON with most content, provided that I keep Frame Delay at 0 and Audio Latency at 64ms.
Symphony of the Night has never been this responsive and, given that it’s one of my favourite titles of all times, this is really exciting. 
Hopefully you can manage to eliminate Sound and Video like you said, so it can get even faster in the future.
I imagine also that, when and if a dynarec is created for this core, the improvements will be once again massive.
Not sure if this has been mentioned, but I came across a funny glitch while testing this on RPI3 using lr-fbalpha and SF2HF (Street Fighter 2 Turbo: Hyper Fighting). With 1 lookahead, the opponent will occasionally switch to your character for several frames. Didn’t try with other settings.
SF2HF is known to be problematic in terms of speed on some emulators due to inaccurate 68k wait state emulation.
Runahead feature is not responsible for savestate bugs in the cores themselves.
Does using the secondary core feature change the results?
In an older post I said I got no picture with Beetle PSX HW, but I was wrong : it’s only the hardware renderer that does not work ; the core runs fine with runahead on software mode.
2 Likes
I haven’t tried running a secondary core for this game. This feature is quite resource intensive on the Pi. I’ll give a go later.
thats strange… file works fine here. im modifying it for gba atm
EDIT: here’s another version, that does the same thing but with less modification. note: this is not a final version, only tested on super mario advance 4, if it still crashes then i dunno why since it works in new released 1.7.2
http://www.mediafire.com/file/drvxvflfcz2in9l/vbam_libretro_input_test_x64.zip
1 Like
It’s working fine now and it reacts in 2 frames, good work!
I had to kill
input_libretro_device_p3 = “0”
to
input_libretro_device_p16 = “0”
that were in my retroarch.cfg.
If only they could never come back again…
I cleaned that already for a problem like that.
Looking at the 1.7.2 release page, there is one more possible trick to get a performance boost on the slower systems.
Instead of sampling audio from the last frame, sample it from the first frame, then use Hard Disable Audio for the subsequent frames. If I can get clean audio with 0 frame runahead for Genesis Plus GX, I’ll probably reinstate the hard audio disable patches.
Edit:
Adding hard_audio_disable and changing runahead to only output audio on the first frame appears to be a 10% speedup.
This would boost Genesis Plus GX on the PS3 from 51FPS to about 57FPS, but that’s still not quite 60FPS.
Edit again:
One other possible optimization would be to not invalidate the tile caches on load state, making it check which bytes have changes and only invaliding those that have changed.
Edit once again:
Got it working! But I have no idea how fast it would run on a PS3 at this point. Probably easily more than 60FPS at this point.
2 Likes
Just tried this out on my Mac and it’s really quite magical.
Thanks for all the hard work!
1 Like
Just tried it with a few SNES, Genesis and PC-Engine games and it works great. Feels all very responsive. One quick question: Any chance that you make the vice_x64_libretro.dll (C64 Emulator) compatible too? That would be amazing. Thanks for you work on that really important matter in emulation.
edit: Ah, this technique relies on save states. And vice doesn’t support it yet. Hopefully this changes in the near future.
If this is working on a PS3 the cpu requirements shouldn’t be that bad. I would expect a high end core 2 duo to handle this for now 16bit stuff and lower.
Looking forward to testing!
@Dwedit wouldn’t it be better to just run the game normally and save the state at the end of every frame, keep the last N frames save states, and when the input changes, roll back of N frames, apply the input and quickly re-emulate N frames within the time of 1 console frame without rendering any of them other than the last? Applying the input to N frames ago will result in the new rendered frame being input lag free. It would definitely be less stressful on the HW than always rendering N frames “per frame”.
I’m quite familiar with how you can save time by only rolling back on dirty input. I’m already doing something very similar with Secondary Core enabled (only resyncs the two cores on dirty input).
The problem is that some features of retroarch (such as Cheevos and Netplay) do not play well with a “Run Frame” function that leaves you in a different state than the very next frame. Right now, I’m ensuring that runahead always leaves the emulator in the same state as if it had run a single frame.