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.

Are you using the D3D or OpenGL backend?

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.

I'm using D3D.

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

How would OpenGL help with input problems?

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.

Can you compare the time stamp of the event with the time stamp when you receive it? Ie, subtract b from a and get the latency? Using al_get_time?

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.

Unfortunately, I can't get OpenGL to work on that machine. In my testing, the input lag is not coming from DirectInput, though.

I placed printf() statements where the DirectInput events are picked up in Allegro's code and some where the Allegro events arrive in my event queue. The console output for the DirectInput events shows up immediately, whereas in my main thread where I process Allegro events, they sometimes show up much later.

I have another computer with Windows that I'm setting up Allegro on right now. I'm going to see if I have the same issue on that machine.

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.

I wasn't able to reproduce the issue on my other machine. I tried the patch and it didn't help. It is probably just an issue with this particular machine. I am having other issues on it as well that might have something to do with it.