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

RetroArch Windows devices
#1

Hi everyone! First of all, I would like to express my utmost appreciation for the hard work poured into the latest versions of Retroarch. I’m always at awe seeing such remarkable technical and artistic talent and the new 1.2 versions really shine in quality and refinement. So thank you for all your work.

Unfortunately I’m experiencing an issue that is not even strictly related to 1.2 versions, since it occurred with previous versions too, but I suppose it would be interesting to bring it up here and evaluate if it can be corrected or at least alleviated.

Basically, regardless entirely of the controller, screen or general setup that I use, I’m experiencing an evident form of input lag with all of the SFC / SNES cores so far available: bSNES, SNES 9X Next or any other alternative. This is very apparent by doing multiple tests with several games that boast precise reaction times and verifying the time the emulator takes to register a certain input and translate it into the action.

Super Mario World is a perfect game to sample the overall amount of input lag, since it features very precise and immediate timings, and it appears as though it may have (especially on bSNES, all versions of it) between 2-3 frames of lag on top of whatever latency may be introduced by other peripherals. This becomes even clearer if you compare the input lag with other cores pertaining to other systems, within the same exact conditions. I have tested NES, GB, GBA, N64, PS1 cores with all sorts of games and they all feel much more responsive than the SNES cores, once again by testing them within the same conditions and using the same devices. I understand it’s most likely something to do with the emulator cores themselves, but I wonder whether this can be addressed or improved somewhat.

Another thing I’d like to mention in this occasion is that, at least on my Windows 7 system, it appears as though the “Disable Windows Composition” option doesn’t work correctly (or at least it doesn’t work as it did on versions 1.0.x). When activated from the corresponding menu it flashes the screen briefly, but then you can see Aero is still unchanged and as active as always.

Thanks in advance for any help. Any insight, especially on the SNES core latency issue, will be extremely appreciated.

#2

Yes, the snes cores indeed are a bit more latent than some of the others. In RetroArch, you can turn on hard GPU sync and increase the frame delay setting (set it as high as you can without getting crackling/stutters; this setting will vary with each core and with special chip games, as they affect how demanding the emulation is).

Other than that, you could use Alcaro’s ZMZ frontend, which only works with SNES libretro cores but has very low latency at the cost of worse sync quality (i.e., has some occasional crackles/stutters).

The composition-disabling being broken is a known issue, unfortunately. It should be making a comeback soon, though.

#3

Thanks a lot for your quick and very informative answer!

Indeed I am already using Hard GPU Sync and it provides me with a very responsive experience all around for most of the cores and systems, but since I always have it enabled (as a sort of common ground for all the cores) the higher latency in SNES emulation does stand out.

With regard to the Frame Delay setting, I’ll definitely try increasing that value. I am no programmer, but just out of sheer curiosity I’m interested in understanding its mechanism and how the ‘Delay’ in the name correlates with the actual outcome in the emulation demand. Just to understand more precisely the inner workings of my favorite software. :slight_smile:

I didn’t know about ZMZ, actually. I’m aware that ZSNES, albeit inaccurate and flawed in so many regards, feels substantially more responsive with its low latency, so I’m going to try it extensively. I wonder though whether it will be possible to implement a similar low latency within Retroarch in the future.

#4

Frame delay works like hard GPU sync in that it delays the input polling and emulation until the last possible instant before vsync. I’m not actually sure how/if they interact together, so I’ll be curious to hear how it treats you.

I’m not altogether sure about why ZSNES and ZMZ’s latency is so great, either. My guess is that it’s related to the primitive syncing implementation (i.e., you trade some latency for freedom from audio crackles and frame stutters). I had thought it could be related to asm+directdraw, but no$snes uses the same and is significantly more latent than ZSNES/ZMZ, so that doesn’t seem to be the case.

Some consoles have internal latency that makes them inherently slower than others, but I don’t know enough about SNES internals to say whether that’s the case here or not. I’ll have to do some measurements with actual hardware to learn more.

#5

I have performed quite a few extensive tests, trying to disregard placebo effects that may compromise my observations. Even though I have no tools to quantify my measurements right now, I feel like increasing ‘Frame Delay’ in conjunction with having ‘Hard GPU Sync’ ON does not produce discernible effects or improve input latency in Retroarch.

On my Windows system I could bring ‘Frame Delay’ up to a maximum of 9-10 before getting lots of crackling and stuttering. At first it seemed a tad more responsive, but I can see there’s still about 2 frames of delay. It makes Super Mario World especially frustrating to play and, when you jump from VBA-M or FCEUMM or even Mupen (which have great perceived input response) to any bSNES core for example, the comparison is jarring to the point of making certain titles unplayable.

I understand that input latency can be a very subjective topic sometimes. Still, any platformer / “twitch” game on SNES is affected and Mario World is a prime example of this: you cannot align jumps well, you slip off ledges constantly, you actually hear the click of the button well before Mario’s jump sound.

I’ll make an attempt with Alcaro’s ZMZ now. If the latency in the Retroarch SNES cores is a byproduct of the syncing implementation that was used, which I understand is very accurate and I’m obviously thankful and grateful for that, could it be possible to give users some degree of customization, allowing them to choose between varying degrees of syncing accuracy vs. input response speed? Or perhaps, I wonder if the current syncing implementation itself can be reworked in the future, since other cores are already achieving a perceived optimal A/V sync (Famicom / NES cores and the others already mentioned) without compromising input response.

EDIT: Alcaro’s ZMZ frontend with libretro cores is indeed much more responsive! It’s a very stark difference and, although I haven’t performed many tests yet, crackling and stuttering are not that frequent.

What I have observed though is that with ZMZ and ZSNES using the in-built VSYNC creates a substantial latency increase, albeit not reaching the level of latency that you can experience with current implementations on Retroarch. With VSYNC off, Super Mario World is once again playable, reactive and fun as it is on the actual SNES hardware.

So, just to summarize (again, sorry for the lack of actual measurements):

  • SNES libretro cores on Retroarch, with Hard GPU Sync OFF: terrible latency;
  • SNES libretro cores on Retroarch, with Hard GPU Sync ON and Frame Delay 0: better latency, but still about 2-3 frames of delay on top of anything else;
  • SNES libretro cores on Retroarch, with Hard GPU Sync ON and Frame Delay 10: very similar if not identical to the previous setup;
  • SNES libretro cores on ZMZ / ZSNES, with VSYNC ON: even better latency, still some delay but improved if compared to Retroarch;
  • SNES libretro cores on ZMZ / ZSNES, with VSYNC OFF: excellent input response, perceived as very similar if not identical to real hardware.

Now, I wonder: if it was possible to have the option of ZMZ-like syncing along with Hard GPU Sync ON on Retroarch, could we achieve the best of both worlds in this regard?

#6

It’s not as accurate as using a high-speed camera or an oscilloscope+photoresistor, but you can do an apples-to-apples comparison of latency among cores using the 240p Test Suite’s “manual lag test”: http://sourceforge.net/projects/testsuite240p/files/?source=navbar You can download versions for SNES and Genesis/MD to compare them.

I’m getting a difference of about 2 frames in SNES (using snes9x and bsnes) vs MD (using genplusgx). That in mind, it can’t really be the overall syncing method that’s at fault, since genplusgx is demonstrably lower-latency running through the same frontend. Testing against ZMZ, my result was somewhere in between. So, while ZMZ is slightly lower-latency than RetroArch, there’s as much or more latency tied up in the SNES cores themselves (or so it seems on my system, at least).

You can try running RetroArch with vsync totally disabled and audio sync on (i.e., blocking on audio instead of video) to see if that helps at all.

#7

Hmm… Unfortunately disabling VSYNC while still maintaining ‘Audio Sync’ ON does not seem to help. I still perceive the same amount of input latency and, once again, Super Mario World provides perfect empirical evidence of this sensation: jumps are terribly sluggish and actions are distinctly delayed.

I’m definitely noticing the same amount of latency that you have mentioned, e.g. about 2 frames on SNES if compared to any other system I’ve tried emulating so far with Retroarch. I guess we can concur that there’s definitely something happening within the SNES emulator cores, that is noticeably affecting the responsiveness of the experience, aside from syncing differences pertaining to the specific quirks of each front-end.

I have also tried the respective Windows stand-alone versions of the SNES cores (Snes9x and bsnes) and indeed they exhibit the same copious latency.

#8

You really shouldn’t have mentioned this. Now that you have, I’ve noticed the slight delay in SNES games, too! I’d imagine that anyone whose played games on that system to death on a CRT will find this unbearable. Other cores don’t exhibit this issue.

If the issue also exists in the standalone emulators as you mentioned, then it wouldn’t be a libretro-specific issue. It’s one that should be looked into, nonetheless.

#9

I have also noticed that Super Mario World is unplayable with the delay. I have tried both wired and wireless controllers, and no noticeable difference.

#10

Glad to know I’m not the only one having this issue. At the beginning, I thought the problem was some specific config on my computer, since SNES9X performs very well with no tearing nor input lag when it has been ported to consoles (Like XBOX), but on PC… Well, no matter what emulator I try, there is just no way to get rid of tearing/input lag (SNESGT gets really close, as far as I can remember, but it lacks nice filters and overlays). Now that I’ve experienced RetroArch and its very pleasant NES emulation, I’m sure something might be broken when it comes to SNES emulation in general.

SNES9X-Next is the only core that feels ALMOST playable in my opinion. Perhaps it can be tweaked somehow?

#11

Yeah, I’ve had this problem since I first started on Retroarch with an early 1.0 version. For whatever reason, the problem is magnified in Super Mario World. Other twitch SNES games I’ve played like Donkey Kong Country or Mega Man X, I see very little lag. There’s still some, but it’s barely noticeable for casual play. Super Mario World however is pretty significant. I’ve played it on the standalone Higan emulator and get the same input lag, so it might not be a Retroarch thing. I haven’t tried the standalone snes9x though.

Right now I’m using the bsnes balanced core in Retroarch, for reference.

#12

There’s something weird going on with Super Mario World’s refresh rate. It seems to be slightly different to other SNES games. I’ve noticed the scrolling isn’t quite 100% smooth - every few seconds it stutters slightly. It’s usually not something you would see because you’re constantly stopping and starting in that game, but if you’ve cleared the enemies out of a certain area and you’re just cruising along you will notice it.

#13

Good to hear that I am not alone experiencing this. I am curious if someone actually got it running without delay or tearing. Or if any developers know what the issue might be?

#14

The stutter actually happens on real hardware too. I tested this after first noticing it on an emulator.

#15

I agree. I have tried several cores now, and all lag compared to the snes9x stand alone emulator. The best of the bunch seems to be bsnes balanced, at least for me (win 7 64 bit). It’s still laggy, but much less than the others.

#16

I’ve already done some latency testing among SNES cores/emus with actual instruments (i.e., no reliance on subjective “feel”):

and there’s another thread on this forum on the subject. In RetroArch, there’s no significant difference among SNES cores, and all SNES cores are higher latency than some of the other cores (for example, genplusgx). Snes9x standalone is a bit lower-latency than RetroArch, but you can improve RetroArch’s results by using hard gpu sync 0 or frame delay as high as you can get without crackling/stuters (they don’t do any better together than alone).

If you want to do comparisons on your own system, use the 240p Test Suite’s manual latency testing utility. However, these results are not applicable to others’ systems and are not really worthwhile for anything other than relative comparisons, as you will mentally compensate for latency while doing the test (that is, just because it reports 0-1 frames of latency doesn’t mean your system has no latency).

#17

I guess this thread begs the question…why?

Is there something inherent in the design of either the snes architecture or (vis-a-vis) the design of every single snes emulator which introduces a noticeable input lag?

The point of “emulation” is to reproduce the experience of using the original hardware. Responsiveness to input is a showstopping problem with regards to this over arching goal.

SNES emulators are very accurate in terms of the visual output at this point - this should be priority number one.

I’d love to hear others chime in and speculate as to what could be the cause. The very same settings and configuration with any other emulator / core produces very satisfying input responsiveness, so it is not a retroarch configuration issue. It is absolutely something with the cores themselves.

#18

[QUOTE=Geomancer;26271] Super Mario World is a perfect game to sample the overall amount of input lag,

.[/QUOTE]

Actually, that’s probably one of the worst games to use when checking for lag. For some reason that game have always had terrible input lag for me, even in other emulators on other platforms. Really weird since it’s the most common snes game. Does anyone know why??? (All other snes games have always worked flawless in terms of lag)

#19

Late to the party, but you guys might also want to check the audio settings. By default the audio latency buffer is set to 64 milliseconds. This means everything you hear is 64ms behind your button presses. I would suggest turning that down as much as you can until you get crackly audio as well. As 64ms of audio latency will give the perception of input lag.

I can get my system down to half that at 32ms before crackling starts. Lower audio latency combined with hard gpu sync has made a difference. I use bsnes-balanced. Not sure if snes9x is better.

#20

[QUOTE=tekn0;33068]Late to the party, but you guys might also want to check the audio settings. By default the audio latency buffer is set to 64 milliseconds. This means everything you hear is 64ms behind your button presses. I would suggest turning that down as much as you can until you get crackly audio as well. As 64ms of audio latency will give the perception of input lag.

I can get my system down to half that at 32ms before crackling starts. Lower audio latency combined with hard gpu sync has made a difference. I use bsnes-balanced. Not sure if snes9x is better.[/QUOTE] Sorry to be frank, but this is missing the point. There is actual objective input lag when using SNES emulators/cores over emulators/cores of other systems. hunterk went through the effort to provide actual calculations that show that. The audio latency setting you’re describing is something completely separate, and I feel certain that everyone who has posted here is already aware of how to handle that.