16 users online:  AmperSam,  Anorakun, ASSATAKKU, Cappaque, Children's Digest 1950-2009, FELIPECOSTA10, Green Jerry, GrenCarret, HeitorPorfirio2006, Kaurrs, Klug, lx5, MorrieTheMagpie, MoxieCat, SubconsciousEye, ToxicRave - Guests: 82 - Bots: 334
Users: 56,258 (2,267 active)
Latest user: BriGuy

Removing SNES Emulation Lag - A Simple Guide

First, while this write-up is my opinion, and comes from my own experience, I've shared it here as a small way to give back to a community that has offered so much. I'll try to update this post as needed.

This guide applies to RetroArch with the snes9x core (for Lunar Magic creators: running emulation in Lunar Magic won't have the same benefits, but switching to RetroArch to playtest longer sections might be useful with these improvements). Typically referred to as input lag – apparent lag in emulation is a sum of a few factors that I'll be concisely describing here.

Motion Blur

I'm addressing this first, because it has made the most impact for removing lag in my own setup. We perceive this affect due to a combination of refresh rates, pixel transitions, and fast on-screen movement. A monitor's own input lag and refresh rate can make this worse (60hz on a 60 fps game means there are always pixels transition-blurring from one frame to the next). Mario for example can appear to be in multiple parts of the screen, blurred.

CRTs do a great job of eliminating this, and while CRT emulation is around the corner, there are options to greatly reduce motion blur available now.

A 240hz+ monitor with its own 'BFI technology' (varies by manufacturer, examples: ULMB, LightBoost, DyAc, ELMB) combined with RetroArch's own Black Frame Insertion option creates an incredibly clear display, close to CRT, for 60FPS retro games like SMW. BFI doesn't create screen flickering that many people are sensitive to, but it does have its own low frequency pulsing. While I consider myself screen-flicker sensitive, I personally don't have issues with BFI during long emulation sessions, although I also disable the monitor's BFI when I'm not using the emulator – as is recommended.

These monitors of course have input lag, and we will adjust for that with RetroArch. Check online or at for the input lag in milliseconds measured for your monitor with BFI enabled. We'll use that number later for the final input lag adjustment.

A 240hz+ monitor outputting at 240hz with its BFI setting enabled.
Older processor's onboard graphics (~pre-2013) may not have a recent enough implementation of HDMI or DisplayPort in order to output to a display at the minimum of 1080p at 240hz.
Many processor's onboard graphics (~pre-2017) may not have a recent enough implementation of HDMI in order to output to a display at the minimum of 1080p at 240hz, but will support this minimum resolution through a DisplayPort signal.

In RetroArch v1.9.1:
Settings > Video > Output > Screen Resolution > Ensure a 240hz resolution is used.
Settings > Video > Output > You may have to select “Set Display-Reported Refresh Rate”, and this will update the Vertical Refresh Rate to what should be 239.x hz (not 240hz, 240 is a nominal term).
Settings > Video > Synchronization > Vertical Sync > On
Settings > Video > Synchronization > Vsync Swap Interval > 2
Settings > Video > Synchronization > Hard GPU Sync > On
Settings > Video > Synchronization > Hard GPU Sync Frames > 0
Settings > Video > Black Frame Insertion > 1

(for Windows 10) Settings > Audio > Output > Audio (driver) > xaudio
The wasapi driver option currently has issues when using fast-forward and rewind in RetroArch. And, on my system at least, is not compatible with the Frame Delay setting we'll be needing at the end of this write-up.

(after selection of audio driver is made) Settings > Audio > Output > Audio Latency > as low as 24, raise if the audio is crackling. On my setup with the xaudio driver, that's 50.

Tada, an incredibly low blur picture, even with fast movement in SMW such as cannon-speed levels.


Now for controllers. I personally recommend an original SNES controller with raphnet's SNES to USB adapter. Raphnet has open source software on their website for controlling the adapter and adjusting its poll interval – which directly affects input lag. I set this to 2ms (equivalent to 500hz polling rate).

While there might be a setup for certain Bluetooth controllers to interface to a PC with low latency, I don't have any documentation available for that. If you own a modern USB controller and prefer to use it – e.g, Xbox, Playstation, 8BitDo – then you have to ensure it supports at least a 500hz polling rate. Tools like UsbTreeView may assist you with verifying that, but I have no documentation.

A short word on the Buffalo USB controller. I discourage purchasing this new; its build quality is incredibly poor. Viewing a disassembly video online, the rubber membranes used are not only proprietary (not replaceable with SNES pads) but also they are not secured to the controller in any way – they are free to move around with use. A big nope. Maybe a knockoff USB SNES controller for an RPG, but certainly not the Buffalo at the price it's sold for.

Back to the polling rate, this is an effect of USB. USB in itself introduces 1 ms of latency, on top of the polling rate which adds a variable latency. I suppose you could have near-zero latency with a SNES controller to parallel port adapter – skipping USB entirely - but I haven't tried! The variable latency of a 500hz USB polling rate is between 0ms and 2 ms, averaging to 1ms – making the total USB latency average to 2ms – not bad.

Your System

PC processors from the last decade should have no trouble accurately emulating the SNES. That's all.

Adjusting for the Known Input Lag in RetroArch

Now we take the two values from earlier: the total average USB latency (2ms) and add the monitor's input lag with BFI enabled (we'll use 4ms as an example). 6ms is the total in this example.

Settings > Latency > Frame Delay > in this example 6

Congrats. Enjoy your lag free setup, with SMW having just its original 2 lag frames - as Shigeru Miyamoto intended.

Special thanks to wye (and  MarioFanGamer) for their ASM when I was doing emulation testing to prepare for this write-up, I wouldn't have gotten the ball rolling without the help!