Kadano.net // SSBM input lag on console and Dolphin/Faster Melee

Disclaimer: This is a writeup about input lag with different hardware and settings. It's aimed more at the technically inclined person than the average user, but worded so that everyone who takes ten minutes of their time to read it carefully should have no problem understanding it. If you just want to know which settings to use in Faster Melee, I will release a separate tutorial for that here [dead link for now].

With the advent of the Faster Melee Dolphin fork, Dan Salvato's polling fix code and later, more advanced versions of his code that are employed in the newer builds of Faster Melee, I feel it has become necessary to have a central reference on input lag in general.
On this page, I want to provide just that by explaining and comparing the different aspects and amounts of input lag from the ground up.

The basics

When we talk about "input lag" in gaming communities, we refer to the delay between a button press on the controller and the corresponding output from the screen.
There are actually two different outputs: video and audio. Both can be subject to lag depending on the software and hardware used. In Melee, we mostly rely on visual cues for reactions like tech-chasing and combos. For situations like shielding fast moves, edgeguarding against some quickly moving recoveries and teching, relying on auditive cues tends to work better.
So, when we talk about "input lag", we should be aware that there are two components to it. The difference between these two – the audio-video sync – should also be kept in mind as something that should be as close to effectively zero as possible.

The signal chain

At any point between the physical button press on your controller and the reception of photons and sound in your eyes and ears, there is potential for input lag in the signal chain in-between. Here is a list of the steps in the signal chain split into rough categories (Signal Chain Step Category):

[SCSC1] Hand to controller port: This includes mechanical properties like button press resistance, stick knob height, and electrical properties like polling frequency.

[SCSC2] Controller port to audio/video output: This is the main category we will be looking at here, since everything we can change by using different software or hardware to run Melee on lies within this step category.

[SCSC3] Audio/video output to output device: In this step category, the electrical outputs from the console / computer AV ports are converted to sound and photon outputs. This includes video output frequency, post-processing devices, monitor lag and audio amplifier delay.

[SCSC4] Output device to human: During this last step, sound and photons travel through the air to reach our ears and eyes.

[SCSC1] Hand to controller port

The differences in delay from different resistances in controller parts are, for the most part, very minor. I will not focus on them within this page, however I want to mention it for completeness' sake. Some controller mods can decrease the time it takes to make a certain input, for example the mod I offer as "B2b" where I insert spacers into the L and R sliders to decrease the movement length necessary to input digital L/R (for air dodge / wavedash). The time difference there is roughly 8-16 ms (depending on finger movement speed), which surely is noticeable.
Another aspect within this category is polling frequency. On console, your controller usually gets polled 120 times a second. Due to the corresponding interval length of 8.33 ms, there is some loss in speed there – in theory, the controller would ideally be polled thousands of times per second, so that even if you start an input one millisecond before the game engine starts calculating the next frame from the controller inputs, your input would still register.
While our polling frequency is effectively 120hz and our game only runs at 60hz, depending on how the polls are aligned with the game engine, there can be different amounts of delay from 0 to about 8.3 ms until a manual input on the controller is picked up and processed. In vanilla Melee, due to currently not fully understood game engine quirks, controller polls are both not in sync and also not processed immediately. These quirks are located in [SCSC2] though and fortunately there is a fix for them.

[SCSC2] Controller port to audio/video output

Again, this is the main category we'll be looking at in this page, and all the software / hardware variables are within here. When you play emulation, there are the aspects of operating system, USB drivers, controller-USB adapter, video and audio plugin type & configuration, graphics card, graphics card configuration, Dolphin version, netplay buffer, Dolphin codes and time elapsed in a match.
On console, there are a few less dependencies: Loader type (in case you use homebrew to load a game disc or .iso), loader configuration (Native Control), codes used, in-game toggles (PAL 50/60hz) and time elapsed in a match.
Most of these variables have quite much to them, so I will expand on them in separate paragraphs below.

[SCSC3] Audio/video output to output device

There are three sub-steps here:
[SCSC3.1] Video output frequency: Only relevant on emulation, not on console. Currently, all video signals output the video information in a (nearly) continuous way. This means that there is a delay between the first line (top of the video) and the last line (bottom of the video) that is roughly equal to [1000ms/(hz)]. For 60 hz, the frame rate most monitors run at, this delay is thus 16.67 milliseconds.
Depending on the standard of measurement definition we use, the refresh rate has a larger or smaller impact on effective total input lag. If we measure at the very first line, this delay is nearly 0 ms even with only 60hz, but if we measure at the last line, it's almost 16.67 ms.
Another aspect closely related to the video output frequency is tearing. Tearing happens when no form of vsync (vertical synchronization) is used, and refers to the frames output by the graphics card being not distinctly separate, but an old and a new frame on top of each other. So the first x lines of the frame are from the last frame (old), and the ones below are from the current frame (new).
If critical video information is being shown at the current frame that is (partly) cut off by the tearing, you will not be able to react to that torn frame as you would be if it had been a proper, non-torn frame. Thus, when measuring video input lag on a system without vsync, it's necessary to use some kind of tearing compensation in order to measure torn frames' input lag in a realistic way.
I personally do this by using two photodiodes. The first is located at 25% from the top of the screen, the second one is 25% from the bottom of the screen. The theorizing behind this is that realistically, nearly all of the visual cues you react to will take place somewhere in the vertical middle of the screen, between these photodiodes, usually closer to the lower one. So whenever the first photodiode receives light at a later point than the second one in a black-to-white scene change (which I use as reference signal), I know that tearing occurred somewhere between the two photodiodes. I then "discard" this frame by not counting from the point of button signal to the point of the lower photodiode activation on this frame, but instead to the point of the lower photodiode activation on the very next frame, where the upper part of the video that was torn from the current frame will be shown.
Whenever there is no tearing, I simply count from the button input signal to the lower photodiode's activation point.

[SCSC3.2] Output device signal processing: If you use any signal processing device between the console cables and the monitor / TV / speakers, they are subject to potential input lag. Some devices are truly lagless (less than 0.1 ms delay), others are not. Due to the many types and models of signal processing devices, I will include lists of them only in a separate page later on.
In addition to processing devices, the output devices themselves also have some delay in signal processing. For all CRT monitors and most CRT TVs, this inherent signal processing delay is completely negligible, with about 1 microsecond (0.001 ms).
For LCD monitors, however, the inherent signal processing delay is usually roughly 3-4 ms on the very fastest ones. These are often labeled "1ms", however that manufacturer specification refers only to the LCD cell response time, which takes place after the signal processing delay. That delay itself is never listed by the manufacturer and can only be found in high-quality product reviews, like those on http://tftcentral.co.uk and http://prad.de.
The signal processing delay is not of a fixed size, but usually dependent on a few menu toggles like "game mode" or "instant mode". The presence of a toggle of that name is no guarantee for the delay itself being low compared to the fastest LCD monitors with that toggle set to on, however.
Audio amplifiers can also have some lag, however setting them to direct mode usually guarantees sub-millisecond delay, so this is no big concern.

[SCSC3.3] Output device response time and type: Different screen types shoot light in different signal curves. This is the reason why the picture on CRTs feels very instant and distinct, but also flickery, while LCDs have a less distinct, blended, smoother picture in general.
Older LCDs, and even some recent ones, can have very slow response times of 12ms and more. Panels of this type make it very difficult to tell some character animations apart, and depending on at what threshold of peak brightness is set to count to, they increase the effective total input lag amount by a medium to large value.

[SCSC4] Output device to human

While the time photons take to reach your eyes is entirely neglectable, with sounds, we should be a bit more careful. You might believe that it doesn't matter how close to the TV you sit in terms of input lag. Whether you sit 2 m away from the TV or very close to it, with your ears within 50 cm of the speakers, actually makes a difference of roughly 5 ms of audio delay. While that is not a lot, it is enough to make the difference of just barely hitting a reaction window or just barely missing it.
To limit the effects of SCSC4, ideally you want to use headphones for in-game audio. This can be achieved by using active distribution amplifiers that split the audio from the console to both the speaker / recording device and to your headphones. This way, the distance of air the sound needs to move through is minimized.
Another benefit of using audio distribution amplifiers is isolation from unwanted sounds – commentators and crowd noise, while still preserving the ability to react to auditive in-game cues.

SCSC2: Polling drift, the different codes that fix it and their effect on AV input lag

After the general overview of the different category steps of the signal chain, this is the first important aspect that I want to focus on in greater detail.
In SSBM, the processor thread that handles polling is not aligned with the game engine properly. Whenever you start a match on console and vanilla SSBM, the polling thread will stay synced for the first 23 seconds, but then start to run asynchronous with an increasing delay, until that delay reaches 25 ms after 16.7¹ seconds, after which it drops to 0 ms again and starts increasing yet again, in an ever-repeating cycle.
¹16.7 is a somewhat rough estimate from stopwatch measurements. The cycle length is probably somewhere between 16.66 and 16.8 seconds.

Below is a chart that illustrates this cycle and how much your inputs are delayed at a certain point in time. I made this chart from console stopwatch measurements, using custom code written by Dan Salvato that shows the current delay between poll and game engine and hundreds of input lag samples taken with an oscilloscope.


So, after the first 23 seconds in a match, all your inputs will be delayed by (on average) roughly 12 milliseconds compared to those first 23 seconds.

A few years ago, Dan Salvato released a code that syncs the polling thread to the game engine, so that the controller inputs are looked at just before the game engine calculates the next frame, instead of using a controller input from up to 25 ms ago, depending on the current point within the poll cycle. Below, you can see an illustration of how the input delay cycle is completely flattened to 0 ms with it:


While from a technical / engineering viewpoint, using this polling fix is clearly superior, competitively there are valid arguments against its inclusion: Techniques that rely on 1-frame windows and tech-chasing become slightly easier / more feasible to do consistently, arguably altering the game balance.
On the other hand, it can be argued that the status quo pushes an unnecessary element of randomness on us, setting limits to the amount of skill one can reach in the game.
However, arguments for and against legality are not what I want to focus on. The important part here is that the polling fix code decreases effective input lag significantly, which can be very useful in some situations. On emulation, you can use the time advantage to set a corresponding netplay buffer, allowing you to play with other people over the internet without exceeding the video input lag you'd have on console + CRT + vanilla SSBM.
On console setups, you can make some previously laggy setups playable – the 12 ms time advantage will compensate similar monitor / TV delays. Some 120hz CRT TVs, for example, lag 12 ms over standard 60hz CRTs when measuring in the middle of the screen – using Dan Salvato's code with such a 120hz CRT TV will make it have the same video input lag as a non-laggy CRT TV.

In the current versions of Faster Melee, an altered version of the polling fix code is used, with additional codes by Achilles and Hannes Mann. This code does things slightly differently than the original one, tying audio output and video output to the game engine (whereas audio is always roughly 16 ms faster than video on console in vanilla SSBM and with Dan Salvato's polling fix code). Comparing these two, the newer one used in FM is 8 ms faster for video, but roughly 6 ms slower for audio.
It's difficult to say whether that's an improvement for FM, since emulation has always had problems with audio delay, at best being roughly 30 ms behind in audio sync over console.
Regardless of that, the newer polling fix code works well on console, giving a useful option to decrease video input lag even more. That, again, can help with making otherwise laggy screens be playable.

Below is a table with my measurements of vanilla SSBM and both polling drift fixes to give a quick comparison.

In addition, here is a chart that compares different hardware / software combinations in audio and video input lag. Values are given for minimum, average and maximum. For emulation, I only included the very fastest configurations that I have measured so far, considering their respective use cases. The Faster Melee sample has been taken with slightly different measurement standards, measuring at 25% up from the bottom of the CRT monitor. I've already subtracted 8 ms from all of its video lag amounts so that it's somewhat comparable to the other ones. (This is the fastest FM audio input lag sample I have so far, I will probably find better ones with further tests, that I haven't done yet for the newer FM versions. I'll update the chart accordingly once I have done so.)

Below is a reference oscilloscope screenshot that shows how the measurements looked when I made them, with a few annotations so that people without experience with oscilloscope can understand what's going on easier.
The statistics at the bottom automatically calculate min, avg and max values from all the samples I measured in one session.
Click on the picture to go to a comparison picture that shows four different sample series I took, three of which are in the table before the chart. (I didn't include one of the FM poll fix 1.2 code ones since the PAL and NTSC values were almost identical.)
The traces are not representative for the average input lag of the respective series, they are simply "random" samples that occurred at the end of the respective series. Only the statistics in the bottom are representative.

Further sections: TBD

More details about my audio lag measurements on Dolphin with different sound cards and settings are here.

Navigation: Back to top – Back to main page