I'm having some trouble getting joystick controls to be responsive on the Windows port of my game. When testing my game, I noticed that the input was inconsistent and laggy. I had initially thought it was some wireless issue, but I hooked up a wired controller and found that it still had the same problem.

I checked the Windows control panel and the input is perfectly responsive there, so I loaded up some of my old Allegro 4 games and they work perfectly fine as well.

I thought I might be doing something wrong in my framework, so I checked the part which handles Allegro's events, and the joystick events themselves are coming in laggy and inconsistent. I get the same thing with ex_joystick_events.

I poked around in Allegro's code to see if I could find a source for the issue there and noticed that there is a delay between when the input events are generated and when they arrive in my event queue. I'm guessing the issue I'm having has something to do with threading.

Is anyone else experiencing similar issues? My game is pretty much unplayable at the moment. I am on a fresh install of Windows 10 with the latest updates.

I don't recall lag, but I do recall some other issues when changing direction with the hat and it wouldn't register the change. Something like that. I ended up dropping joystick support entirely anyhow.

Try OpenGL, and see if it helps. There's a know issue with D3D and input lag (usually noticed on keyboard events though).

So for Direct3D, there's this concept of a lost device (e.g. happens when you lock your screen while your game is playing). For various reasons that are probably not valid right now, we check quite often in the main input thread that the device is not lost. That check is surprisingly expensive, and has lead to delays in the past. We can probably turn it off now, but before that it's easier to just try OpenGL. OpenGL doesn't have the concept of lost devices, so it doesn't have that extra step.

The bug I'm referring to won't show up like that, you'd need to look at the platform's event timestamp and compare it to the event's timestamp. Allegro its event timestamp after the delay already happened.

If it's another cause, then this would show it though.

If you're compiling Allegro yourself, I've attached a patch you could try. If you're using the official binaries, I can also compile you a copy with that patch included.