I try not to make assumptions as to what people are aware of. Posters in this thread, lurkers, or future readers. I was just trying to help.
Since I can’t solve the actual problem, I can only make suggestions to help make it better. This made it better.
Any news regarding this issue?
it’s very hardware configuration dependent and platform dependent, it’s not an easy issue to fix, maybe not something RA can fix at all.
This is an issue with the core itself. I have verified that Snes9x as well as Higan running natively without RA produce similar lag. The only emulator which seemed as responsive as I needed it to be was BizHawk. But that is one gimped emulator if you like features.
I tested both Retroarch and ZMZ with and without desktop composition enabled. Tested from 240p suite. I get around 2-3 frames delay with Retroarch with desktop enabled. Without it, I get around 1-1.5 frames delay. ZMZ was similar with desktop composition. ZMZ seems to be very responsive without desktop composition. I could only test it on the laptop since it’s windows 7 that has desktop composition option.
I also tested this on my desktop windows 10 by switching to exclusive fullscreen and has 1-1.5 frames delay. Hard Sync didn’t affect much. ZMZ only works on windowed since ddraw is broken on fullscreen. I also tested Genesis gx with vsync or windowed in windows 10 and I would get around 0.5 frames or sometimes excellent reflexes in 240p suite.
I’ve always had the same issue with SNES in Retroarch.
FINALLY!!!
I’m trying RetroArch Nightly Build 2016-02-17 (x86_64), VSync ON, Hard GPU Sync ON, and there is ABSOLUTELY NO MORE INPUT LAG FOR SNES! Tried first with Core Snes9x_Next, which works almost perfect (Setting Frame Delay to 8 or 10 makes it perfect for me), then I tried BSNES_Mercury_Balanced core, and Oh, My Gosh! Even at Frame Delay 0 it works like a charm! I don’t know what kind of black magic was used to accomplish this, but THANK YOU! Now I will finally play and finish Super Mario World and Chrono Trigger once again.
Can anybody else try and confirm, please? =)
I was under the impression that frame delay is redundant if you’re using hard GPU sync. Is that right?
In my testing, yes, but whatever. YMMV.
Would using the 240p Test Suite manual lag test be an acceptable way of testing input lag ? I know there are more fancy ways of testing it and all that but if you don’t have the equipment for it and you don’t want to just go by “feel” in a game.
It’s better than nothing. However, our brains are very good at adapting to latency*, so as you use the test suite, you will begin compensating for the latency involuntarily. This introduces some inconsistency in testing that’s pretty much unavoidable. Again, it’s better than nothing but just remember that your results are not applicable to anyone else’s results, and the frame values are only slightly useful even in the few contexts where they’re not totally useless.
*http://blogs.scientificamerican.com/observations/time-on-the-brain-how-you-are-always-living-in-the-past-and-other-quirks-of-perception/ ^^ scroll down to the bit about David Eagleman
Oh yeah I completely agree with you on the brain adapting to latency. I noticed immediately when I first checked out the 240p Suite Test that if you sat there and did the input lag test more than a couple of times you start to compensate for it and without even thinking about it and try and game the test. I found the best way to do it is come at it “cold” and just fire it up and do it once and be done.
Obviously there are much more accurate and scientific tests out there that are way better but I and im sure many others out there who do not have the equipment to do those tests.
It’s good to know that the 240p test is at least a suitable quick and dirty solution rather than just firing up a game and testing that way.
Just to add to this thread about SNES core input lag I fired up the 240p suite in both the Snes9x and bSnes Accuracy cores and both were around the 15 - 20 ms (1 frame) mark on 2 quick “cold” tests which from my understanding is probably about the best that can be expected on an average run of the mill (non gaming) lcd monitor.
Awesome.
I was waiting for v 1.3.1, but if SNES input lag is fixed, I might have to update sooner.
I tested a bit (in disbelief, I have to admit! 
) and didn’t see much difference with snes9x.
But, bsnes mercury balanced seems more responsive to me. Played some F-zero I play a lot these days, and it feels smoother while turning in opposite directions. Mario World feels more responsive too.
I just use hard sync 0. Guess it’s good-bye to snes9x for me.
might be related to the new polling method, check input settings, input polling should be set to late now by default (late = better I don’t know the full reasoning behind this but it seems to work)
I tested this on both windowed and exclusive fullscreen. Both Snes9x and Bsnes cores have perfect response. I kept getting excellent reflexes with and without hard sync. I get a lot of red negative frames, which is harder to pass, and got around 2/10 frames. I set fullscreen exclusive instead of windowed since I’m on windows 10 which lacks the disable desktop composition option. If you want a perfect response time, use exclusive fullscreen or use disable desktop composition if you are in windows 7 or below. On windowed, I usually get the same input lag as previous builds. This only works without windows vsync. I never got any change of hard sync and I would get the same response on either windowed or fullscreen, respectively.
Hmm… I’m using the latest nightly on my Windows 7 x64 setup and I am frankly not perceiving any substantial change right now if compared to the previous versions of Retroarch and bsnes. 2 full frames of delay and Mario World feels exactly the same.
With the same configuration used with version 1.2, I am still registering the same stark and blatant difference in immediacy between some very responsive system cores (like NES, PS1 and especially GBA) and all of the SNES ones, which give a sluggish impression still to this day.
I have noticed the new Poll Type Behavior option which is definitely interesting. As far as I could gather, it is wise to leave it at ‘late’ since it should poll inputs quite more timely, but I understand it is something that applies to the ecosystem as a whole: any and every difference that existed between the individual cores in terms of latency would still be maintained.
Moreover, the “Disable Desktop Composition” still seems to be broken in Windows 7, which is unfortunate since eliminating that would determine an even more reactive experience and I remember it did work around version 0.99.
Are you trying BSNES or BSNES Mercury?, Mercury made the difference for me.
Did you try disabling this manually in Windows?
Yes, I have always been using BSNES Mercury Balanced for my input response tests. So far I’m not noticing any specific change with regards to latency.
If you are talking about toggling between the themes in Windows as a general configuration, thus disabling DWM and Aero for the whole OS, that would work but it would also defeat the purpose of having an internal option in Retroarch, which at the moment appears to have no effect.
I think using exclusive fullscreen in Retroarch is like disabling aero. (video -> windowed fullscreen mode OFF)
I can feel the difference with mercury. Perhaps something else is a source of lag in your setup?
I play with a wired x360 pad on a 18ms display lag TV here (saw that in a review, can’t measure it myself 
).