Hi Brunnis. Great investigation! Are you able to do a test with Vulkan? Also, where is your snes9x-next-libretro fork repository? Can you put it on github?
Thx @Brunnis for the deeper investigation and the first solution. And thx for @Tasuya79 for the DLL.
It realy seems faster for around 1 frame when I test with 240pSuite. With the Dell U2715 I get around 1.8 frames in average.
Realy great effort @Brunnis keep going!
Hope some of the other devs also get into deeper investigation to get rid of some of the lag frames.
I tried to apply the same trick to snes9x (not “Next”). I did the change on Github if anyone wants to check that, should be easier to read.
Here is the core for win x64:
snes9x_libretro (Brunnis test input lag fix)
I always feel Snes9X is slightly slower than Next or Bsnes…
Is this real?
Anyway that’s quite close now. 
[QUOTE=Tatsuya79;41391]I tried to apply the same trick to snes9x (not “Next”). I did the change on Github if anyone wants to check that, should be easier to read.
Here is the core for win x64:
snes9x_libretro (Brunnis test input lag fix)
I always feel Snes9X is slightly slower than Next or Bsnes… Is this real? Anyway that’s quite close now. :)[/QUOTE] That’s awesome! Do you want me to test it before/after using the camera method as well? If the fix works as expected, I’ll create a bug report on GitHub. I just made one for snes9x-next here:
I’ll see if I can test with Vulkan as well, but I don’t really expect any improvement. Given the figues I’ve collected so far, it appears that less than one frame of delay (maybe even less than half a frame) is added between the finished frame being output from the emulator and the monitor starting to scan out the frame at the top left. Both the tested graphics card and the display seem to be exceptionally fast in getting a frame out…
EDIT: Ohh, and I don’t have a fork repository set up. I’ll see if I can do something about that.
great work!
honestly, i think if you want dev feedback i’d create a pull request on github rather than an issue. it would give a nice easy view of your diff rather than having to download the source code and compare manually, plus people can add comments in-line for any concerns.
[QUOTE=dankcushions;41394]great work!
honestly, i think if you want dev feedback i’d create a pull request on github rather than an issue. it would give a nice easy view of your diff rather than having to download the source code and compare manually, plus people can add comments in-line for any concerns.[/QUOTE] Thanks, dankcushions! I’ll see if I can try that approach instead.
Yes that’s definitely something I’d like to know I you feel like doing more testing.
Quick comment:
FYI regarding additional input lag in Retroarch running on Linux: https://github.com/libretro/RetroArch/issues/3100 (modification shaves half a frame off on average)
Also, Lakka has now been modified upstream to apply the rt-kernel patch for more consistent scheduling with 1Khz tick rate, preemptible etc. (frame delay setting can be increased further)
The above two changes makes the input lag in Linux as low as seen on Win10.
It would be interesting to test how many games this fix of mine actually works on… If the game polls input early, i.e. before the vblank interval, the fix is not effective (well, if I’ve understood things correctly, that is). However, the result should still not be worse than without the fix. Anyone care to help out by testing snes9x-next with and without the fix, using the frame advance method? I’d like to test myself, but I don’t have time right now (and might not until next week).
[QUOTE=larskj;41434]Quick comment:
FYI regarding additional input lag in Retroarch running on Linux: https://github.com/libretro/RetroArch/issues/3100 (modification shaves half a frame off on average)
Also, Lakka has now been modified upstream to apply the rt-kernel patch for more consistent scheduling with 1Khz tick rate, preemptible etc. (frame delay setting can be increased further)
The above two changes makes the input lag in Linux as low as seen on Win10.[/QUOTE]
Very interesting! I’ll definitely want to test this.
How could we do this for bsnes-mercury balanced?
I think perhaps in this part here:
But I don’t understand the code there…
Bsnes is a LLE hardware emulator, so it polls exactly when the SNES would poll, right? I also don’t fully understand the source, but I skimmed through a bunch of files including timing.cpp and scheduler.cpp and that’s what it seemed like. I might be totally wrong here.
I’m having a pretty bizarre discussion (or lack thereof) in my thread on byuu’s forum at the moment… The thread starts with some old stuff regarding my first test results. The discussion about the code change in snes9x-next begins here: http://board.byuu.org/phpbb3/viewtopic.php?f=8&t=1058&start=10#p26925
They either misunderstand the intent of the fix, ignore the test results or simply state something along the lines of “we’ve discussed input lag before and there’s nothing to be done in the emulator”. Maybe this supposed fix is so stupid that I don’t even deserve to be told why it won’t work? I just wish someone would tell me what I’m missing. Looks like byuu’s just ignoring me now…
In the meantime, I’ve started testing a list of games with and without my fix in snes9x-next by using the frame-advance method:
[TABLE=“width: 283”]
Stock With fix
SMW2: Yoshi’s Island 4 3
Super Metroid 3 2
Super Mario World 4 3
[/TABLE]
So far, things look good. Interesting that Super Metroid has one frame of lag less than SMW and SMW2.
Keep up the good work, luckily the source code is available so we can apply these kinds of improvements ourselves.
It would be very interesting to apply the same to bsnes mercury when we figure out how.
They tested input lag over and over again… with higan/bsnes/snes9x standalone.
Perhaps Retroarch and GPU hard sync play a role in the results we get. I mean, perhaps something like you did was considered “not enough to bother with” on those emulators that have more input lag. (or that breaks stuff and they could say clearly what)
Because in the end… that’s working here and I’m enjoying Super Aleste with lower lag than ever before.
I tried several methods with bsnes like doing the input polling after the frame rendering but perhaps that’s completely wrong. (moved some function calls from CPU to PPU…) I mean it compiles and works but the input lag is unchanged.
I’m not an expert on this though that’s for sure! just tweaking and testing.
Does the improvement show in camera-based testing, as well? If so, there’s not really much to deny.
Despite the comments on byuu’s forum, it shouldn’t have anything to do with which scanline you’re rendering on, but if you want to test an interlaced game, R.P.M. Racing is interlaced all the time, even in menus (which is probably where you’ll need to test).
Input lag has been the only factor that caused me to step away from the RPi as an emulation platform and emulation in general. When I saw this thread pop up I created an account on these forums just to post in this thread. I compiled the Snes9x-Next core with the fix on my RPi and compiled the latest version of RetroArch with the dispmanx bilinear filtering fix and it has renewed my interest in emulation. Even being just a couple of frames it makes a huge difference to someone like me that is very sensitive to latency. Just wanted to say thanks for the work you’re doing on this matter.
[QUOTE=larskj;41476]Keep up the good work, luckily the source code is available so we can apply these kinds of improvements ourselves.
It would be very interesting to apply the same to bsnes mercury when we figure out how.[/QUOTE] Yep. I’ll see if I can have a look, but I will probably be in over my head…
[QUOTE=Tatsuya79;41479]They tested input lag over and over again… with higan/bsnes/snes9x standalone.
Perhaps Retroarch and GPU hard sync play a role in the results we get.
I mean, perhaps something like you did was considered “not enough to bother with” on those emulators that have more input lag.
(or that breaks stuff and they could say clearly what)[/quote]
Yeah, it could well be that this doesn’t apply outside of RetroArch. I never claimed I was sure that it would, so I’d expect a little less arrogance. Can’t say I’m surprised, though. I work as an engineer in electrical and software engineering and it’s not the first time I’ve run into big egos and buckets of arrogance in this world. I don’t take it personal, though. I’ll just save myself some time and stop posting over there.
[QUOTE=Tatsuya79;41479]I tried several methods with bsnes like doing the input polling after the frame rendering but perhaps that’s completely wrong. (moved some function calls from CPU to PPU…) I mean it compiles and works but the input lag is unchanged.
I’m not an expert on this though that’s for sure! just tweaking and testing.[/QUOTE] Keep looking at it! If the solution can’t be applied to bsnes, we should try to understand what differs in the implementaiton.
Yep, it does. That’s what makes the denial so bizarre… 
Thanks for the tip. I’ll give it a try.
Great to hear and you’re welcome!
Just tried R.P.M racing OMG…
This game feels like it has 1s lag on any emulator anyway!
A bit unrelated but I was playing “Kat’s Run - Zen-Nihon K-Car Senshuken” a mode7 racing game (that feels like and indie game really). The sound bugs completely on snes9x, it’s OK on Next but with some graphical glitches in the demo. Bsnes is perfect.
Not the 1st time snes9x has some bugs that are worse than Next while it should be the opposite.
There’s probably more issues like this on obscure games, which make bsnes a better all-around bet.
edit: removed, doesn’t work.
I only had time to do a very quick test with the snes9x cores and… wow, what a difference! It is absolutely and definitely crystal clear to me that there’s an improvement in responsiveness. It’s really great.
Super Mario World is way more playable now: just doing quick jumps here and there feels much closer to the immediacy of real hardware and I have a CRT setup with the actual cartridge and SNES to compare. I have also perceived that, by disabling Audio Sync in Retroarch, you get even better latency, although that might be a mere placebo effect on my part.
Now, the only problem with snes9x is that, as many have noted, it has a few quirks that affect the overall result. One of these has to do with audio latency: while I can bring this value down to 30-32ms on bsnes (with the xaudio driver) with no repercussions whatsoever, on both snes9x cores this leads to very choppy audio playback forcing the user to keep a relatively high value (64ms)
Ideally we would need a WASAPI / ASIO driver on Windows to achieve exclusive bit-perfect playback and get very low audio latency, which in turn would lead to an even better sensation of responsiveness. I have already posted this on github: https://github.com/libretro/RetroArch/issues/2771
Thank you Brunnis and everyone involved! Keep up the good work, I hope bsnes can be likewise modified.