An input lag investigation


Slightly unrelated but not that much, run ahead 2nd instance is working for FBA now.
You need to update the core and RA too (Dwedit fixed something there).

There’s many games where you can save 3 or 4 frames of lag.


Is Galaga ‘88 supported in FBA? That game’s input lag is atrocious for a SHMUP and even with a CRT and Groovymame with a high frame delay it’s just not good


Yes it’s here.
3 frames of lag you can remove.


Is runahead capable of mult thread / core performance?

What would be the best cpus to use the max of run ahead? I have an i7 6700k at 4.5ghz and it doesn’t seem enough for 4k bsnes higan with 2 instances. Using nSide helps a bit.

Testing Super Metroid and I get some frame drops.


The bigger issue with bsnes/higan and runahead is that non-deterministic savestates will cause internal desyncs. What this means is that sometimes a button you’re holding down will involuntarily release for a frame, causing, for example, charge shots to fire unexpectedly, etc.


But that’s not what I’m experiencing here. I can see fps going down to 50-55 fps when playing.

I guess this must be related to my cpu performance. Maybe I’m wrong.


Right, that’s unrelated. I was just letting you know that bsnes/higan isn’t really ideal for runahead anyway.

For your specific issue, you can try opening your system monitor/process viewer and see if any of your CPU cores are getting maxed out. If not, something else is likely dragging you down.


Hi guys, I was just trying out D3D9 hardware overlays, and wanted to know if that could be an answer to low latency in Windowed mode. I do see tearing when I rapidly display things, which seems like a good sign.

Edit: Nope, there appears to be an extra frame of latency in there.


I wrote a simple DX9 program that rapidly calls Present in Flip Mode, so there will be realtime tearing on the screen. I made it display Black most of the time then display While while holding Enter.

On my laptop in Fullscreen mode, it ended up having roughly one frame worth of input lag between hitting enter and the program changing the screen color on the screen.

I also tested it in Windowed mode, resulting in one additional frame of input lag. I also tested using an Overlay surface, and while that did show tearing, it did not have any lower lag than a vsynced display.


I was just comparing the input lag of my keyboard vs the input lag of my 8bitdo controller, and was surprised to find this: Connecting the controller via USB cable is laggier than connecting it by Bluetooth.


I made some pretty pictures showing off various input lag I got.

Clips were taken with cellphone camera recording at 120FPS.

First, real NES on a CRT. On the third frame, finger comes in contact with the button, and top of screen is immediately brightened. Zero lag whatsoever.

In order to respond instantly to a button press, it’s using some custom Game Genie codes that change The Legend of Kage into a input lag tester.


Second, my little DX9 Input Lag tester program using the Enter key to trigger the display to change color. Despite updating the screen immediately, and showing tearing, it still manages to have about 16.66ms of lag before anything actually appears on the screen.


Third, using an 8bitdo controller instead of a keyboard. One more half-frame of lag than with the keyboard, very good for a bluetooth device.



This matches my own findings with my 8bitdo SFC30. I measured 8-10 ms extra lag compared to a standard USB device. Quite good and a small number compared to the other usual input lag sources.


Acording to the DS4Windows, when using bluetooth, the Playstation 4 controller comunicates to 250hz(4ms) by default but selectable up to 1ms, and when using the cable the default usb comunication would be at 125hz(8ms). Maybe 4ms is default for every BT controller on Windows. Here some info about dx and its different presentation modes and latencies and


My little test program is already using a zero-latency mode (Exclusive Fullscreen + Flip with vsync off), but thanks for linking that youtube video.


No problem. When usin 120hz refresh rates (crt, freesync, etc) I believe the latency is cut in half of that of 60hz (in conjunction with the use of a frame delay value close to 8 might eliminate the full frame of lag of the api). but the use of black frame insertion for smoothness, darkens the screen. The black frame insertion demo of blur busters site has a “brightness equalizer” to counter that Can something similar be done for retro arch? maybe a shader or gama bust?


The brightness equalizer in that example unfortunately is going the other way :stuck_out_tongue:

It’s darkening the 30 fps and 60 fps by 50% rather than brightening the BFI one.

AFAIK, the only way to improve the brightness in BFI is to increase the brightness of the monitor. That is, if we try to increase it in software, we’re just going to get a bunch of clipping, as we’re already at the limits of brightness with a normal image.


oh, I see. What about a gamma bust like the FPGA Super NT does, or even the FightCade version of FBA has a gamma setting(by both software and hardware methods) for compensating the scanline filter. Or what if we change the black frame to a gray or white frame instead, or that will result in a washed like image?


Sorry to go backwards and nooby on you Brunnis(and everyone else) but I’m having the hardest time googling an explanation on Windows 10 USB polling. I’ve read articles in the past on Windows about using PS/2 ports and all to cut usb lag but still don’t understand if it’s still an issue on W10. This post seems to say it does. Everytime I trying googling W10 usb polling, I get vague results talking about mouse and not gamepads and joysticks. So can you Brunnis or anyone else here help me understand how to fix it and if I buy an expensive HORI Joystick for PC does it have 1000hz automatically turned on so I can play fighters with no issue or do I have to manually set the polling? Or…someone can just point me in the right direction? Again really sorry to go backwards here guys but I have horrible google skills and it’s been years with no straight answers. Please help!!!


There is no latency/polling issue with USB in Windows. It all works automatically. The most commonly used (and slowest) polling frequency is 125 Hz, but devices themselves are free to request faster poll rates (250 Hz, 500 Hz and a maximum of 1000 Hz). The host system reads this device configuration info during bus enumeration and Windows will honor this out of the box.

Unfortunately, faster polling rates than 125 Hz are not all that common. For some reason, it’s mostly used for mice (which is probably why you mainly found info on this when googling). But, as long as the device you’re connecting requests faster poll rate, it will work fine. For example, I’m using the Raphnet Wii to USB adapter for my SNES Classic Mini controllers and it’s a 1000 Hz USB device. Windows handles this correctly.

In short: no manual configuration of poll rates is necessary.

By the way, trying to force a higher poll rate than what a device requests can be tricky, but that’s a different discussion. :slight_smile:


Could you elaborate on that?

In the past I stopped using Sweetlow’s USB hack, as I would find it behaving erratically even though USBView would show it changed the bInterval to 0x01 for the patched device.


Not really. :slight_smile: Well, it’s just that it usually requires hacks and third party tools, which may be tricky to implement (depending on the user’s computer knowledge, of course).