经常检查LWJGL / JInput游戏手柄按钮或轴时滞后，如何解决？

Question

I'm in the process of creating a multiplatform (but OpenGL favoring) game engine on Java for Android/OUYA and PC, and the PC platform adapter is giving me some issues when rapidly checking gamepad state.

I'm currently using LWJGL/JInput to write the PC adapter, and whenever I poll gamepad state faster than about 30 times a second (giving about 33ms to do the poll and update the state), the values obtained from the gamepad are false. False in the sense that the stick can be halfway to the right, and yet getAxisValue returns 0 instead of something near 0.5f out of 1f. On top of that, it seems to take longer than the 33ms that would be fine otherwise when asked to do it more often. What gives?

In a nutshell, what happens on a typical update call is that the engine scans through the active players' controllers for the state of specific buttons that are actually used in the game, all set and registered ahead of time. At the moment, in my test app, that consists of two buttons and an axis. So all it's doing is checking the current state of three inputs, no more. After being passed through a couple layers of interfaces and into a switch block, eventually this is called:

return controller.isButtonPressed(map.A);

or

return controller.getAxisValue(map.LS_H);

where map contains final ints that link names to specific index values for the given controller.

What I've found through my own testing:

• This isn't a hardware issue, as it stays pretty accurate when below 30 to 35 updates per second.
• When ramping the speed up to about 60 updates a second to match the 60fps rate of the graphics thread, it causes massive lag on the input thread only. The graphics thread is not affected, which makes me think that it isn't a general performance issue either.
• Changing isButtonPressed or getAxisValue to arbitrary preset values solves the update lag issues, so it isn't my code causing the intermittent stops, definitely isButtonPressed and getAxisValue.

Is there any way to improve the speed of gamepad checking, or some setting somewhere that I missed that disables unnecessary input routines through LWJGL/JInput?

Is matching 60fps too much to ask in terms of performance?

Answer 1

Polling isn't the best way, it's a relatively expensive operation. Take a look at the event interface on JInput, you should be able to check the contents of the event queue quickly.

Answer 2

Turns out part of the visual lag I was experiencing was due to an issue with my loop's delta-t calculation. It was based on the time between the end of the previous frame and the start of the new frame, throwing out the time taken to perform the calculations on the previous frame. This led to a visual stutter on frames that took longer, making any small performance issue appear huge. Fixing this helped visual stuttering, but didn't improve gamepad lag (time between moving an axis and seeing the result) or accuracy of input readings (axis physically at X but reading as 0 or something non-X).

---

What Fixed It:

I narrowed down some of the problems that were causing time wastage:

• Display.update() automatically polls the input, which is already being done in the logic thread. It is possible that calling it from the rendering thread caused a locking issue between threads, making the logic thread wait for the rendering thread to release the input objects. Another consideration is that polling is now happening significantly more often . Using Display.update(false) and letting the logic thread poll on its own reduced issues considerably.

• Display.setVSyncEnabled(true) forced the rendering thread to use the entirety of its given rendering time (13ms for a 60fps rate) on my 60hz monitor, possibly exacerbating the previous locking issue. Enabling it always worsened the logic thread's stutter before removing the input polling from Display.update()

• Optionally using Display.swapBuffers() instead of Display.update(false) seems to have a minimal improvement on performance. In my code, the latter tends to cause intermittent frame lag.

After implementing these changes, I haven't noticed any issues with gamepad readings, and the engine is extremely responsive to axis changes. The highest I've tested without visual stutter on my hardware is 60fps rendering and 100cycles/second on the logic/input thread.

---

I believe part of the issue on a mentality level is that I am attempting to poll input hardware independently of the rendering process, which LWJGL doesn't seem to encourage due to Display.update() being tied to both input polling and the screen buffers. By the way the API is implemented, it is impossible to use some input devices without having established the display.