Heavy input lag with every SNES / SFC core + Disabling Desktop Comp. not working

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! :slight_smile: ) 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 :stuck_out_tongue: ).

[QUOTE=Tatsuya79;34990]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 :stuck_out_tongue: ).[/QUOTE]

Same here, I’m using a wired x360 pad on one of the lowest-lag screens on the market. The thing is, there might be a slight improvement in the most up-to-date release of bsnes-mercury, but the difference between even bsnes-mercury and something like mGBA is still appalling. This is further evidenced by the 240p suite on the SNES core still consistently reporting a measurement of 2 frames of lag, while the other system cores provide much more responsive results.

It’s the SNES cores themselves that actually boast this high degree of lag, not Retroarch as an enviroment. There is something in both snes9x and bsnes (all of their respective forms so far) that produce a consistent input delay of about 2 frames.

Now you actually made me curious, Geomancer. Do you notice any difference regarding Input Lag by enabling and disabling VSync? (Hard Sync always ON). To me, stable release feels 100% responsive when VSync is off, of course the damn thing becomes completely unplayable for me because of the tearing, but it’s very responsive, you could try with a game that has an extremely responsive jump, like Aladdin, and see what happens.

Also, what processor and video card are you using?

It seems to be specifically snes cores that was the problem. I never had noticable lag on nes, genesis gx, or other cores I’ve tested at least on windowed with Windowed Vsync. I even tested my htpc with 47 inch screen with Xbox 360 wireless and I notice no lag when testing 240p suite and it was actually hard to not get negative frames.I haven’t tested the snes cores yet for htpc

How can you make RetroArch select Bsnes_Mercury automatically? It picks the regular version. Ever since you can’t select cores in the cfgs there is no way to control this as far as i know.