1,809
edits
Changes
Jump to navigation
Jump to search
grammar
'''Input lag''' is the delay between pressing a button and seeing the game react.<ref>http://www.anandtech.com/show/2803</ref> The potential causes for "input lag" are described below (steps which have negligible contributions to the input lag have been omitted). Each step in the process increases "input lag", however , the net result may be unnoticeable if the overall "input lag" is low enough.
==Causes==
===GPU driver latency===
There is video latency caused by the GL drivers in Windows/Linux. Both the GLX X11 and Windows GL/D3D drivers are full of hacks, codepathscode paths, and buffer schemes that cater to benchmarking applications and games. This is counter productive counterproductive when the aim is low-latency audio and video synchronization for emulators. You don't want all this stuff going on in the background.
Hard GPU sync options in some emulator frontends can reduce or remove latency from buffering at the possible expense of performance.
This can be avoided by using [https://en.wikipedia.org/wiki/Mode_setting KMS] and [https://en.wikipedia.org/wiki/Direct_Rendering_Manager DRM]/[https://en.wikipedia.org/wiki/EGL_(API) EGL], specifically on Linux. By using these modes, the user is in control of front and back buffers and don't have to rely on APIs, so that they can find where and when a frame was dropped and how to act accordingly with that in mind. It is advisable to get the latest driver to improve performance, as notable graphics chip manufacturers (e.g. AMD, Nvidia) do not find KMS a priority. Intel graphics chips, however, should be fine regardless, but it is still advisable to update drivers.
Low-level APIs such as Vulkan give the user control over buffering, and may lower latency without resource-heavy solutions like hard GPU sync. However, there is evidence that OpenGL has lower latency than Vulkan in some instances.<ref>https://forums.libretro.com/t/an-input-lag-investigation/4407/291</ref>
===Controller===
*CRT TV or monitor
If you don't have a CRT or can't be bothered with one, you can mitigate input lag on LCDs by setting the display to game mode if available, and also only pass them their native resolution. This turns off some post-processing effects, and reduces scaling delay, which both introduce lag.
To disable Windows Aero under Windows Vista/7, select the Basic or Classic theme under Control Center > Personalization, or disable desktop composition under .exe properties > Compatibility. Some emulators and frontends allow you to disable desktop composition without having to switch themes. Desktop The desktop composition will also be disabled by playing under the non-windowed full -screenmode. In Windows 8 and later, the desktop composition cannot be disabled manually.
Triple buffering will inherently add a few frames of latency. So disable that wherever possible, either through emulator settings or driver settings.
Some graphic graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands<ref>https://www.twentymilliseconds.com/post/latency-mitigation-strategies/#toc_7</ref>. [[RetroArch]]'s Hard Sync does this.
[[File:Vsync and Predictive Waiting.png]]
Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option to delay the processing of emulation for a few milliseconds until right before a vsync occurs, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) vsync period. The amount of time you can use frame delay without dropping frames is dependent on the performance of the emulator on your machine. Predictive waiting may also be forced with any DirectX based program through GeDoSaTo<ref>http://blog.metaclassofnil.com/?p=715</ref>.
Realistically, this is the last thing to configure, after all , other sync and buffer settings have been configured for your system's performance. It is only useful with significantly more power than is required to run at full speed.
==References==
