Could it be implemented as a Core Option feature maybe? That way the priority of accuracy would still be preserved in the code, while allowing the user to manually activate this lag fix whenever playing normal commercial games.
Hunterk, does it mean we can use the patch on the Android version of Snes9x-next ?
@Tromzy Yeah, just fetch the newest one from the online updater and it should have it.
@Geomancer Possibly. It’s hard to make core options out of some things, but I’ll look into it.
More games tested with the latest modified bsnes-balanced code, using the pause-method:
Aero the Acro-bat: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Earthbound: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Kirby Super Star: 3 frames (Brunnis’ fix) vs. 4 frames (original bsnes-mercury) Megaman & Bass: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Super Ghouls and Ghosts: 2 frames for attacking, 3 frames for jumping (Brunnis’ fix) vs. 3 frames for attacking, 4 frames for jumping (original bsnes-mercury) Super Mario All-Stars: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Zombies ate my Neighbours: 3 frames (Brunnis’ fix) vs. 4 frames (original bsnes-mercury)
FYI, the bsnes-mercury lag fix patch has now been added and merged to Lakka as well.
If updating Lakka to try this, make sure to delete any previous bsnes so file in /Storage/Cores/ (only necessary if you have updated bsnes mercury previously from within Lakka)
Super Mario World is actually playable now 
Geomancer - Out of curiosity, what game did you test with in Super Mario All-Stars? I noted you have 2 emulation frames from All-Stars but 3 for Super Mario World stand-alone-game.
[QUOTE=Geomancer;41672]More games tested with the latest modified bsnes-balanced code, using the pause-method:
Aero the Acro-bat: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Earthbound: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Kirby Super Star: 3 frames (Brunnis’ fix) vs. 4 frames (original bsnes-mercury) Megaman & Bass: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Super Ghouls and Ghosts: 2 frames for attacking, 3 frames for jumping (Brunnis’ fix) vs. 3 frames for attacking, 4 frames for jumping (original bsnes-mercury) Super Mario All-Stars: 2 frames (Brunnis’ fix) vs. 3 frames (original bsnes-mercury) Zombies ate my Neighbours: 3 frames (Brunnis’ fix) vs. 4 frames (original bsnes-mercury)[/QUOTE]
I have so far tested Super Mario Bros. 1 and The Lost Levels within All-Stars and they both exhibit 2 frames of latency with the new fix. Bear in mind that the version I’ve tried is the one without SMW.
I also confirm that standalone Super Mario World features 3 frames of lag (4 with original bsnes-mercury).
It’s how the games are programmed.
Just tried several Mario World version (USA, Japan, All-stars pack, Arcade) they all have 3 frames lag. Then Mario 1, 2, 3 have 2 frames.
This is so great for SNES! Finally Super Mario World and Yoshi’s Island feel in RA like they do on the real console! I can almost start practicing speed running on emulator! The only thing stopping it is the vsync issue with audio sync (drops many frames every few seconds instead of just 1 every ~10 seconds as it should running at 60.099Hz on a 60Hz display). I’ll mention that issue somewhere else. It might be an Nvidia Vulkan driver issue.
Requested cores to investigate for applicability of this awesome “Brunnis lag fix”, with some games I like that I think would benefit greatly from it:
Nestopia (Chip and Dale: Rescue Rangers) mGBA (Mother 3, Castlevania: Aria of Sorrow) mupen (Super Smash Bros.) desmume (Castlevania: Portrait of Ruin)
I agree, but it would be nice to know for sure if there’s an extra frame of input latency and that the feeling isn’t just a placebo.
I noticed that a while ago, in super mario world it stutters every 10 seconds or so when you’re running around.
With the Pause method:
Mgba Super Mario Advance = 2 frames Nestopia Chip n Dale = 2 frames
No problem there it seems.
Nestopia Batman = 2 frames get ready to jump, 9th frame is in the air.
But that’s just the way it is. I can finish it in less than half an hour anyway, one of my all time favourite.
To be clear for anyone confused, the input lag you feel is something like:
game code / design choices + emulator (core) processing time (Pause method we give here) + Retroarch dealing with all these “Operating sytem dependant timings” + your joypad response time + your monitor/TV response time
Brunnis fix is at the emulator / core level. Then you can hope for Vulkan? faster standards for peripherals? Retroarch magic?
Yeah, my mGBA results seem indeed consistent with yours, Tatsuya. It’s actually one of my favourite emulators out there: lightweight and responsive, with extremely low audio latency, great accuracy while not too taxing on the CPU.
I think Brunnis’ fix has brought the SNES core back in line with the others as far as processing time is concerned. Now I wonder if it’s possible to further reduce emulator latency and get to the point of seeing a reaction time of just one frame.
It is just pure speculation on my part and I don’t have any programming competency either, but the fact that the lowest amount of latency we’re experiencing on all cores (even the fastest ones) is of 2 frames makes me wonder if we may look at something at a Retroarch-wide level to decrease it further.
The reason I’m making this assumption is that there is another libretro frontend that actually appears to be even more reactive than what we have measured so far. I’m talking about Alcaro’s ZMZ, which couples the old ZSNES interface with the SNES libretro cores. You can find it here: http://www.smwcentral.net/?p=section&a=details&id=5681 Here is its github page: https://github.com/Alcaro/ZMZ
Back when I made the other thread on SNES latency, hunterk advised me to try it and I immediately noticed a huge improvement, although the timings were not as buttery-smooth as in Retroarch. Hunterk references this difference with actual measurements on his blog page: http://filthypants.blogspot.it/2015/06/latency-testing.html
I have made a quick test by using the latest Brunnis-fixed cores within ZMZ and it seems even more responsive, to the point of starting to really resemble actual SNES hardware.
I wouldn’t really know where to start honestly, but maybe Brunnis might find something relevant by comparing the two programs.
Another interesting resource, mentioned also by hunterk, might be to look at Calamity’s GroovyMAME, available here: http://forum.arcadecontrols.com/index.php/board,52.0.html It’s a special distribution of MAME that diverges from baseline thanks to several features aimed at CRT usage (but it also works on common LCD screens) and minimizing latency. As far as I can understand, they have implemented two things that make it great from an input-lag perspective: a d3d9ex backend which supposedly skips all sorts of driver overhead and a “frame_delay” function. They claim to achieve next-frame latency on Windows x64, so once again I wonder if we can look at it as a reference.
I tested those programs before, but ZMZ seemed very hacky and I couldn’t see myself using this regularly. About GroovyMAME I didn’t get much out of it, don’t know if I missed some settings. ShmupMame looked interesting to me too but it can’t do shaders and is a bit outdated. I don’t remember if I tested it in the end.
The latency tests Hunterk made are strange to me, particularly on the shader part within Retroarch. I’m using CRT geom all the time and it’s just impossible it would give twice the response time vs stock.
I can go between both with the N & M keys while making mario jump on bsnes: difference is hard to tell. It can’t be 86 vs 148ms while I can feel the 16ms difference Brunnis fix makes. I put it on some kind of problem, AMD drivers with cg shaders or something.
And there is this “RetroArch - fullscreen Hard GPU Sync = 0 bsnes-compatibility core xbr-lvl4-multipass” at 80ms average Vs ZMZ fullscreen 78ms that looks strange too compared to the other cases.
With Brunnis’ fix and using frame delay of 4, everything feels instant to me (w/ 1 frame of LCD lag). Have you tried fiddling with that setting?
Yes, I actually pushed it all the way to 7 and I agree, with the Brunnis-fixed cores it feels almost instant, at least subjectively.
Don’t get me wrong, the results Brunnis has achieved with the SNES cores are outstanding and make things way more playable and responsive than before. Once again, I can’t be thankful enough.
I’m just asking myself whether it is possible to theoretically shave one further frame off in the actual emulator processing code, the one we’re measuring through the pause-method, and achieve a minimum latency of just 1 frame there. ZMZ and other solutions out there are surely way more hack-ish and inaccurate than Retroarch as far as timings go, but maybe there’s something useful in there.
I’m not sure about that frame delay setting.
I test it with bsnes-mercury balanced, GPU Hard Sync is ON @0.
Mario World accepts frame delay 5 maximum, is it really faster? I can’t tell for sure Then Super Aleste can go to frame delay 10. Sometimes I feel it’s fast, sometimes the same, I really can’t tell.
In the end I put it on OFF as I’m afraid it could cause frame skipping / stuttering in different games / cores.
what about the input polling option in settings > input called “poll type behavior” that may help when set to “late” vs “early” or “normal” ? did anyone get any numbers for that? i think the fix is great but i still think there is a need for a nice spreadsheet detailing all the various latency related settings, and how many frames they save (or add!).
Does V-Sync still add one frame latency? I remembered testing mgba with real hardware using GBA-SP and NDS and I scroll the settings in Pokemon and Mario main menus with d-pads and recorded with 60fps camera, and I get 4 frames response when scrolling on those system and using Retroarch without vsync. With vsync with hard off or on, I would get one frame added, and this goes on both amd and nvidia cards.
However, I get better response with N64 in RA than other emulators, especially testing Doom 64 and Quake.
Also, it’s nice to keep track on SNES cores getting better response time.
Thanks everyone for testing out the code change in bsnes-mercury!
Thanks a lot for this! I will spend some time tomorrow looking at what possible side effects this change could have.
Unless I’ve misunderstood it (and I havent’ spent much time on it), this setting is not all that interesting in most cases. Setting it to “late” allows the input to be polled when the emulator requests it. As far as I can see, the libretro implementation must be specifically written to utilize this. If the input is simply polled before calling the emulator main loop, the “late” setting doesn’t make a difference. The reason that this setting isn’t very interesting is:
- In most cases, the emulator loop is constructed so that input is read almost immediately after entering the loop. This is what snes9x-next and bsnes-mercury with my fix do. Whether we poll input from the system just before or just after entering the emulator main loop will not make any meaningful difference in this case.
- Even for emulators that poll late (such as snes9x-next without my fix), “Poll type behavior” set to “late” is not of much use unless the emulator executes rather slowly. If the emulator loop runs quickly, like in a millisecond or two, polling early or late during the loop obviously won’t make much difference (i.e. only a couple of milliseconds at most).
So, in summary, you’d need a combination of pretty slow emulation and an emulator that polls late to reap any benefits from this setting.
I’ll try this with camera recording on my rig. I believe my 6700K should allow for a quite high frame delay setting.
I honestly don’t think there is much more to do in the emulator(s). I believe the 2-3 frames that it now takes with snes9x-next and bsnes-mercury is inherent to the actual console/games.
On that same theme, I’ve spent a lot of time today looking at the Nestopia source code. Long story short (yeah, it took a while to sift through the sources…): I don’t think Nestopia suffers from the 1 frame additional input lag, like the SNES emulators. Although the source code was a little hard to follow, it looks like Nestopia does the right thing, i.e.:
- Polls input.
- Kicks off emulator right at the start of VBLANK.
- Exits the emulator loop right when the frame has been generated.
I haven’t used the frame advance method on many games with Nestopia, but I have tested Mega Man 2 and it showed 2 frames of emulator input lag. This matches what the SNES emulators can do with my fix and my current hypothesis is that the NES games also have some inherent lag that we probably can’t get rid of.