Changes

 ;Display choice

*Wired controller'''2.''' Turn off digital image processing and [https://youtu.be/input device (just for minimizing possible negative factors, just like NzYvudM9BmI?t=723 frame generation] options. If you're using wired connection for router intensive one turn off post-processing effects from applications/emulators and client device)[https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel].:'''2.1.''' Turn on DLSS/FSR upscaling technologies [https://youtu.be/-ajK3netvv4?t=173 if it increases your framerate which will likely decrease your latency].

*'''3.''' Use exclusive fullscreen for Windows 8 and onwards if available because with borderless windowed and windowed fullscreen, due to [[Wikipediahttps:Windows_Display_Driver_Model#WDDM_1//emulation.gametechwiki.com/index.2php?search=%22%23Enhancements|WDDM Enhancements%22&title=Special%3ASearch&limit=500&profile=default&fulltext=1 input lag-mitigating techniques] if application supports it.:'''3.1.2]''' A relatively new lag-mitigating technique known as [https://github.com/higan-emu/emulation-articles/tree/master/input/run-ahead Run-Ahead] has recently been implemented in several emulators and frontends, which leverages spare performance overhead to run one or more instances of the emulator ahead of the regular instance, then uses save state rollback to lay that instance over what you see, effectively cutting a whole frame or more of input lag. Most games, even on real hardware on a CRT, have at least one hard-coded frame between executing an action on the desktop composition cannot be disabled anymorecontroller and said action being reflected on screen, so your only hope setting Run-Ahead to avoid 1 frame cuts out that superfluous frame and thus is usually considered safe, but setting it to 2 or more can result in dropped frames and perceived video stutter (though some games can benefit from 2 or more frames, particularly a lot of 5th-gen games). This is also quite processor-heavy, as every extra Run-Ahead frame requires a whole extra instance of the emulator, easily doubling or tripling CPU load, and some emulators are currently not able to use Run-Ahead at all. That said, combined with all the compositing other lag penalty is to play reduction techniques on a sufficiently powerful system, Run-Ahead in theory can actually result in exclusive fullscreen modeless input lag than even real hardware.:'''3.2.''' Another option for lag-mitigating technique known as Preemptive Frames. See [https://www.youtube.com/watch?v=NDYqRoyOKI4 this video] for information.

*Turn off digital image processing and '''4.''' Always make sure that your [https://youtu.be/7DPqtPFX4xo?t=72 GPU is underutilized] for preventing [https://youtu.be/NzYvudM9BmIK_k1mjDeVEo?t=723 83 render queue bottleneck] which causes considerable amount of input lag. If that is the case use framerate capping such as "in-game frame generationcapping" or equivalent option from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel] options. If you're Another option to prevent this is simply using intensive one turn off post[[Vsync|V-processing effects SYNC (from NVCP)]] with Low Latency Mode: ULTRA from applications/emulators and [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]; this will automatically prevent "render queue bottleneck".**Turn on DLSS<ref name=renderqueueandvsyncbackpressure>[https://www.nvidia.com/en-us/geforce/guides/gfecnt/202010/FSR upscaling technologies system-latency-optimization-guide/ Nvidia: System latency optimization guide], [https://youtuforums.blurbusters.becom/-ajK3netvv4viewtopic.php?t=173 if it increases your framerate which will likely decrease your 8645 BlurBusters thread: Nvidia Reflex and low latencymode].</ref>

*Use [https://emulation'''5.gametechwiki.com/index.php?search=%22%23Enhancements|Enhancements%22&title=Special%3ASearch&limit=500&profile=default&fulltext=1 input lag-mitigating techniques] if application supports it.**A relatively new lag-mitigating technique known as [https://github.com/higan-emu/emulation-articles/tree/master/input/run-ahead Run-Ahead] has recently been implemented in several emulators and frontends, which leverages spare performance overhead to run one or more instances of the emulator ahead of the regular instance, then uses save state rollback to lay that instance over what you see, effectively cutting a whole frame or more of input lag. Most games, even on real hardware on a CRT, have at least one hard-coded frame between executing an action on the controller and said action being reflected on screen, so setting Run-Ahead to 1 frame cuts out that superfluous frame and thus is usually considered safe, but setting it to 2 or more can result in dropped frames and perceived video stutter (though some games can benefit from 2 or more frames, particularly a lot of 5th-gen games). This is also quite processor-heavy, as every extra Run-Ahead frame requires a whole extra instance of the emulator, easily doubling or tripling CPU load, and some emulators are currently not able to use Run-Ahead at all. That said, combined with all the other lag reduction techniques on a sufficiently powerful system, Run-Ahead in theory can actually result in less input lag than even real hardware.**Another option for lag-mitigating technique known as Preemptive Frames. See [https://www.youtube.com/watch?v=NDYqRoyOKI4 this video] for information. *Always make sure that your [https://youtu.be/7DPqtPFX4xo?t=72 GPU is underutilized] for preventing [https://youtu.be/K_k1mjDeVEo?t=83 render queue bottleneck] which causes considerable amount of input lag. If that is the case use framerate capping such as "in-game frame capping" or equivalent option from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]. Another option to prevent this is simply using [[Vsync|V-SYNC (from NVCP)]] with Low Latency Mode: ULTRA from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]; this will automatically prevent "render queue bottleneck".<ref name=renderqueueandvsyncbackpressure>[https://www.nvidia.com/en-us/geforce/guides/gfecnt/202010/system-latency-optimization-guide/ Nvidia: System latency optimization guide], [https://forums.blurbusters.com/viewtopic.php?t=8645 BlurBusters thread: Nvidia Reflex and low latency mode]</ref> *''' Using [[Vsync|V-SYNC]] without "capping framerate limit to below your display's refresh rate" OR without "using Low Latency Mode: ULTRA or Anti-Lag+" will result "V-SYNC backpressure" which will cause additional input lag [https://youtu.be/L07t_mY2LEU?t=530 (especially if it includes triple buffering)]. To prevent this use framerate capping such as "in-game frame capping" or equivalent option from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]. Another option to prevent this is simply using [[Vsync|V-SYNC (from NVCP)]] with Low Latency Mode: ULTRA from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]; this will automatically prevent "V-SYNC backpressure".<ref name=renderqueueandvsyncbackpressure></ref> Keep in mind that if you're using AMD Anti-Lag+ and have a VRR monitor and also want to eliminate tearing completely [https://youtu.be/K_k1mjDeVEo?t=727 you need to use framerate limiter unfortunately because it does not keep the framerate inside the variable refresh rate range of the monitor] unlike Nvidia's solutions.**:'''5.1.''' Instead of manually capping framerate or using "Low Latency/Anti-Lag" features from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel], you could simply use [https://youtu.be/7DPqtPFX4xo?t=650 NVIDIA Reflex feature] from in-game, but unfortunately not all [https://www.nvidia.com/en-gb/geforce/technologies/reflex/supported-products/ games supports this feature].**:'''5.2.''' Some graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands. RetroArch's [[Vsync#Hard_GPU_Sync|Synchronization Fences/Hard Sync]] for OpenGL does this. If you're using Vulkan backend, be sure to set the [https://arm-software.github.io/vulkan_best_practice_for_mobile_developers/samples/performance/swapchain_images/swapchain_images_tutorial.html max swapchain images] parameter to 2, though weaker GPUs (especially Intel iGPUs), can struggle with this, particularly if using intensive [[Shader_Presets|shader presets]] or increasing [[Resolution|internal or rendering resolution]].**:'''5.3.''' Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option named "[https://www.libretro.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Frame Delay]" to delay the processing of emulation for a few milliseconds until right before the given V-SYNC frame period is over, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the newer V-SYNC frame period. The amount of time you can use Frame Delay without dropping frames is dependent on the performance of the emulator on your machine. Use [https://www.libretro.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Automatic Frame Delay] if you don't want to manually give a value for Frame Delay. Keep in mind that realistically, Frame Delay is the last thing to configure, after all other "sync and buffer settings" and "Input lag mitigation techniques" have been configured for your system's performance, as it gives the least lag reduction bang for your CPU load buck. ''Also "Predictive waiting" may also be forced with any DirectX based program through'' [https://community.pcgamingwiki.com/files/file/897-gedosato/ GeDoSaTo].----;Summary It cannot be understated how much system requirements increase the more lag reduction measures are employed. A computer or device that would normally be able to run an emulator or core at full speed with ease can suddenly find itself chugging with said measures implemented, especially once Run-Ahead and Frame Delay come into play, which may necessitate foregoing some of them. Some ways to alleviate the load and unlock more lag mitigation potential include making sure performance options are enabled, turning on speed hacks or dynarecs if applicable (to the extent that they don't hamper the game significantly, that is), or switching to faster, less accurate emulator/cores altogether, as the less CPU intensive an emulator is, the more performance overhead is left over for lag reduction. An example would be switching from bsnes to SNES9X, which trades cycle accuracy and compatibility with a handful of games for far greater performance and thus more room to reduce input lag. Also, as implied before, if you have to choose between Run-Ahead and Frame Delay, you should almost always choose Run-Ahead. Of course, if your system is powerful enough to run the most accurate emulators along with all the input lag reduction techniques all at once, go ahead and do so.