Have not tried that test but afaik jme3-lwjgl uses LWJGL 2 (which is not maintained anymore by the maintainer) and uses jInput for joystick input detection whereas jme3-lwjgl3 uses LWJGL 3 which uses GLFW. Maybe that’s the reason for different results!
One quirk I’ve seen with LWJGL 2 is that, on Xbox controllers at least, the triggers map to the same axis, with one trigger pushing negative values and one pushing positive. This means that if both triggers are pressed, this will result in the axis being 0. Also, on Linux, I’ve seen some gamepads get shown twice on the computer. However, this can pretty easily be fixed by telling your project to rely in JInput 2.0.9 as I describe here.
With LWJGL 3, on the other hand, my gamepad has a couple of the axis that share the same name as the bumpers. This breaks the remapper and prevents it from getting all the buttons working. This is rare, and I’m actively working on a fix for this, but
Besides that, I’ve noticed that the default remapper file in jme3-core tends to be configured for LWJGL 2. However, besides the issue above, I’ve found LWJGL 3 to be more reliable.
Thanks everyone for the help. I have a project created with NetBeans using the version of jme3.2.4 and jme3-lwjgl on Windows OS. I didn’t notice it before, but updating the project with gradle using template build.gradle, I realized that using jme3-lwjgl3 the joystick doesn’t work as before.
Reading @Markil3’s post I thought I’d test the two libraries with the TestJoystick.java class to better understand the differences.
Correct me if I’m wrong:
jme3-lwjgl2 + jinput 2.0.9 is reliable but is no longer maintained.
jme3-lwjgl3 is the new standard, but maybe it has some flaws.
What do you suggest to use for the development of a new demo?
Pretty much. As I said, XInput gamepads like Xbox 360 ones will have problems on Windows, but it seems to be pretty reliable otherwise.
One idea would be to have an option in your game settings that allows you to switch between LWJGL 2 and LWJGL 3 upon restarting the application. This would probably involve creating a custom batch script and/or exe that can read that option and change the classpath in response, and it will probably involve maintaining two different compatibility mapping files for each version, but it could be useful in case one API doesn’t work very well with your user’s gamepad.