Fix joystick and gamepad library before jME 3.1 stable?

Momoko_Fan · October 24, 2015, 4:48pm

All of these issues will probably get resolved once we switch to LWJGL3, which uses GLFW internally instead of JInput to manage joysticks.

Yves_Tanas · October 24, 2015, 6:13pm

So i cannot do anything about it ?

pspeed · October 24, 2015, 6:25pm

What is that the output from? What does the output from TestJoystick look like (not run from test chooser but run on its own?)

Note: TestJoystick will also create a joysticks-NUMBER.txt file for easy pasting.

As far as I know, TestJoystick doesn’t produce any output like you’ve included.

If you turn the logging level for com.jme3.input.lwjgl.JInputJoyInput to FINE then you will also get additional info about what is going on with joystick detection in JME.

zzuegg · October 24, 2015, 6:40pm

It is the output from plain jinput. But the issue with the TestJoystick is tracked down. And the output from jinput suggests that the hotas should work with jme out of the box.

As it stands currently i am not sure if there is something else todo beside fixing the testchooser and the missing support for separate rumblers

Ogli · October 25, 2015, 4:42pm

Nice hint, Tankwart, with this I was able to track down version numbers:

jinput test v2 uses jinput 1.0.0-b01
jME 3.0 Stable uses jinput 1.0.0-b01
jME 3.1 Alpha 1 uses jinput 2.05
jME 3.1 master* uses latest stable LWJGL (3.0.0b build 35) without jinput (now GLFW)
*-> seems like this is being configured manually by user DannyJo

Thanks, this info was extremely valuable for me in order to understand.
Looked it up in the LWJGL3 wiki and found some strange things right away:

the mouse cursor coords will start at top right in LWJGL3 compared to bottom left in LWJGL2 (I hope that this won’t cause any serious confusions)
there is a maximum of 16 joysticks in LWJGL3 and a macro constant (GLFW_JOYSTICK_1, GLFW_JOYSTICK_2, …) for each of them. DirectInput has no such limitation of 16 devices and I’m lucky that my party game testing will be okay with 10 gamepads (my room is quite small), but sorry for anybody who wants to try my party game with more than 16 people…

Hm, have I missed something? Do you mean that TestChooser problem or something else?

I just sent a PM message to Yves that he should run the TestJoystick.java directly again (in version 3.0 and in 3.1 of jME SDK). But I have doubts, because he had already sent me a video where I could see his space game using pspeed’s TestJoystick graphics in action with Yves gamepad. We shall see what Yves reports back later.

Regarding the rumble function:
I simply did not have enough time yet for this and probably will fool around with that during next week: Look up some examples in the LWJGL2 docs, ask in their forum if anybody has experience with this topic.
Also, I have jME SDK 3.1 alpha 1 too and will try my TestRumble.java in it.
Also, maybe I will be able to create a short LWJGL3 test with rumblers.

@pspeed
I just recently noticed that maybe this thread could be interpreted as criticism against your prior work on the joystick integration. Just know, that it was never intended in such a way. I just see a problem and want a solution. You made a good job back then and sacrificed some of your time (and time is the limiting factor for many things, as most of us will surely agree). We shall see if rumble (force feedback) will ever really work in the end, as zzuegg suggested there may be problems in the underlying drivers / operating systems.

Ogli · October 26, 2015, 12:41pm

Hm … bad news … I had a look at GLFW and things are bad, here’s what I found out:

GLFW has no support for force feedback and will not until GLFW 3.2 is out (says 3.2 is “18% complete” - and regarding their progress in the past, this will take … another year or more).
GLFW currently uses winmm, which is an API from the 1990s when joysticks were still attached to sound cards, has been replaced by DirectX / DirectInput a long time ago. The API is bad and somewhere between XInput und DirectInput (XInput: 4 axes, winmm: 6 axes, DirectInput: 8 axes for joysticks).
GLFW only supports polling for joysticks, no events, no callbacks. This means that during low frame rates like 20 or 30 fps button clicks might get unnoticed. Some players will even face this with 60 fps.
Currently you get “quirky values”, especially under Windows 8.1 as people in the LWJGL wiki and in the GLFW forum reported.
no meta-info on joystick axes or buttons in the GLFW API. winmm has some names for the axes and buttons, but this should be obsolete, since what I saw were 1990s flight sticks (x,y,z axis, uv axis, some buttons).
the afore mentioned 16 devices maximum and 6 axes per joystick maximum (which is easily reached and to make things worse, the “coolie hat switch” / “dpad” is sometimes an axis and sometimes buttons and with no meta info (see #5) you can’t determine it).
XInput is supported since GLFW 3.1.1 (05/2015), says “optional at compile-time”, but since XInput is inferior in terms of features when compared to DirectInput, and even lower then winmm in many ways, this is only useful for people coding for XBox gamepad or Windows Store. Also, the API does not seem to have a rumble or force feedback, because it still is the old GLFW API.

So, long story short: They will need a lot more time to achieve similar support for gaming devices like jinput. We can only hope that GLFW version 3.2 will provide a proper DirectInput interface like they say.

I really would like to be able to select the input library. Maybe make input as flexible as selecting renderer, i.e. like JOGL or LWJGL, would be appreciated by users like me.

pspeed · October 26, 2015, 1:10pm

I’m confused by this threads various offshoots… is there actually a problem with the latest version of JInput?

Ogli · October 26, 2015, 1:27pm

We had these two sub-topics and their respective status currently is:

Hotas stick not working in jME but in jinput test v2
→ waiting for Yves latest reply (I told him to run TestJoystick in 3.1 SDK directly)
→ I downloaded the source for the jinput test v2 and will compare it to jME (find differences)

Rumble (force feedback) problems
→ I will test it with jME 3.1 to find out if things got better than in jME 3.0 (back then: semi-kaput)
→ I will read jinput documentation to find out how to make it right
→ I will try to find users in LWJGL Forum who have experience with that topic
EDIT: → we will definitely want to access motors seperately (via jME API enhancement)

New topic #3: jinput will get replaced by GLFW in 3.1 stable
→ one might want to make a spin-off thread for this topic, yes…

pspeed · October 26, 2015, 7:03pm

All indications so far is that it will work fine the test is run properly.

Yes, better rumble support is needed regardless of underlying API. Is there a limitation in JInput itself that prevents this?

I think this is a HUGE mistake to switch. GLFW sounds very primitive in comparison where as so far JInput works fine. There would have to be a really strong and compelling reason to move and I haven’t seen it.

Yves_Tanas · October 26, 2015, 8:03pm

So i ran the Testchooser out of JME 3.0 and 3.1 Alpha SDK.
The output shows, it should work, but i cannot use it.
Whenever i try to use joystick, i run into this error.
And yes: i can connect my gamepad and fly away as i have done before.
I think i posted it upwards, didn’t i ?

run:
Okt 26, 2015 9:08:13 PM net.java.games.input.DefaultControllerEnvironment getControllers
WARNUNG: Found unknown Windows version: Windows 8.1
Okt 26, 2015 9:08:13 PM net.java.games.input.DefaultControllerEnvironment getControllers
INFORMATION: Attempting to use default windows plug-in.
Okt 26, 2015 9:08:13 PM net.java.games.input.DefaultControllerEnvironment getControllers
INFORMATION: Loading: net.java.games.input.DirectAndRawInputEnvironmentPlugin
Okt 26, 2015 9:08:13 PM net.java.games.input.ControllerEnvironment log
INFORMATION: Failed to initialize device USB Keyboard because of: java.io.IOException: Failed to acquire device (8007001e)

HID-Tastatur
114
Keyboard
Unknown
0
Back
Tab
Return
Left Shift
Left Control
Left Alt
Pause
Caps Lock
Kana
Kana
Kana
Kanji
Kanji
Escape
Convert

Pg Up
Pg Down
End
Home
Left
Up
Right
Down
SysRq
Insert
Delete
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Left Windows
Right Windows
Apps
Sleep
Num 0
Num 1
Num 2
Num 3
Num 4
Num 5
Num 6
Num 7
Num 8
Num 9
Multiply
Num +
Num ,
Num -
Num .
Num /
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
Num Lock
Scroll Lock
Num =
Num =
Left Shift
Right Shift
Left Control
Right Control
Left Alt
Right Alt
,
.
~
[
]
Ax

HID-Tastatur
114
Keyboard
Unknown
0
Back
Tab
Return
Left Shift
Left Control
Left Alt
Pause
Caps Lock
Kana
Kana
Kana
Kanji
Kanji
Escape
Convert

Pg Up
Pg Down
End
Home
Left
Up
Right
Down
SysRq
Insert
Delete
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Left Windows
Right Windows
Apps
Sleep
Num 0
Num 1
Num 2
Num 3
Num 4
Num 5
Num 6
Num 7
Num 8
Num 9
Multiply
Num +
Num ,
Num -
Num .
Num /
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
Num Lock
Scroll Lock
Num =
Num =
Left Shift
Right Shift
Left Control
Right Control
Left Alt
Right Alt
,
.
~
[
]
Ax

HID-konforme Maus
19
Mouse
Unknown
0
x
y
z
Left
Right
Middle
3
4
5
6
7
8
9
10
11
12
13
14
15

HID-Tastatur
114
Keyboard
Unknown
0
Back
Tab
Return
Left Shift
Left Control
Left Alt
Pause
Caps Lock
Kana
Kana
Kana
Kanji
Kanji
Escape
Convert

Pg Up
Pg Down
End
Home
Left
Up
Right
Down
SysRq
Insert
Delete
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Left Windows
Right Windows
Apps
Sleep
Num 0
Num 1
Num 2
Num 3
Num 4
Num 5
Num 6
Num 7
Num 8
Num 9
Multiply
Num +
Num ,
Num -
Num .
Num /
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
Num Lock
Scroll Lock
Num =
Num =
Left Shift
Right Shift
Left Control
Right Control
Left Alt
Right Alt
,
.
~
[
]
Ax

USB Receiver
0
Unknown
Unknown
0

USB Keyboard
0
Unknown
Unknown
0

USB Receiver
0
Unknown
Unknown
0

T.Flight Hotas X
18
Stick
Unknown
0
Taste 0
Taste 1
Taste 2
Taste 3
Taste 4
Taste 5
Taste 6
Taste 7
Taste 8
Taste 9
Taste 10
Taste 11
Mehrwegeschalter
X-Achse
Y-Achse
Schieberegler
Z-Rotation
Z-Achse

USB Keyboard
3
Unknown
Unknown
0
Systemstromversorgung
Systemenergiesparmodus
Systemaktivierung

USB Receiver
0
Unknown
Unknown
0

USB Keyboard
31
Unknown
Unknown
0
Taste 0
Steuerungsgerät
Numerischer Tastenblock
Taste 3
Taste 4
Taste 5
Taste 6
Taste 7
Taste 8
Taste 9
Taste 10
Taste 11
Taste 12
Taste 13
Taste 14
Taste 15
Taste 16
Taste 17
Taste 18
Taste 19
Taste 20
Taste 21
Taste 22
Taste 23
Taste 24
Taste 25
Taste 26
Taste 27
Taste 28
Taste 29
Taste 30

USB Receiver
31
Unknown
Unknown
0
Steuerungsgerät
Numerischer Tastenblock
Taste 2
Taste 3
Taste 4
Taste 5
Taste 6
Taste 7
Taste 8
Taste 9
Taste 10
Taste 11
Taste 12
Taste 13
Taste 14
Taste 15
Taste 16
Taste 17
Taste 18
Taste 19
Taste 20
Taste 21
Taste 22
Taste 23
Taste 24
Taste 25
Taste 26
Taste 27
Taste 28
Taste 29
Taste 30

USB Receiver
3
Unknown
Unknown
0
Systemenergiesparmodus
Systemstromversorgung
Systemaktivierung

USB Keyboard
0
Unknown
Unknown
0

USB Receiver
0
Unknown
Unknown
0
BUILD SUCCESSFUL (total time: 1 second)

Okt 26, 2015 9:09:39 PM java.util.prefs.WindowsPreferences
WARNUNG: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(…) returned error code 5.
Okt 26, 2015 9:09:41 PM com.jme3.system.JmeDesktopSystem initialize
INFORMATION: Running on jMonkeyEngine 3.1-alpha1

Branch: master

Git Hash: c5c893f

Build Date: 2015-08-17
Okt 26, 2015 9:09:42 PM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFORMATION: LWJGL 2.9.3 context running on thread jME3 Main

Graphics Adapter: nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx

Driver Version: 10.18.13.5850

Scaling Factor: 1
Okt 26, 2015 9:09:42 PM com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFORMATION: OpenGL Renderer Information

Vendor: NVIDIA Corporation

Renderer: GeForce GTX 970/PCIe/SSE2

OpenGL Version: 4.5.0 NVIDIA 358.50

GLSL Version: 4.50 NVIDIA

Profile: Compatibility
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: Audio Device: OpenAL Soft
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: Audio Vendor: OpenAL Community
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: Audio Renderer: OpenAL Soft
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: Audio Version: 1.1 ALSOFT 1.15.1
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: ALC extensions: ALC_ENUMERATE_ALL_EXT ALC_ENUMERATION_EXT ALC_EXT_CAPTURE ALC_EXT_DEDICATED ALC_EXT_disconnect ALC_EXT_EFX ALC_EXT_thread_local_context ALC_SOFT_loopback
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: AL extensions: AL_EXT_ALAW AL_EXT_DOUBLE AL_EXT_EXPONENT_DISTANCE AL_EXT_FLOAT32 AL_EXT_IMA4 AL_EXT_LINEAR_DISTANCE AL_EXT_MCFORMATS AL_EXT_MULAW AL_EXT_MULAW_MCFORMATS AL_EXT_OFFSET AL_EXT_source_distance_model AL_LOKI_quadriphonic AL_SOFT_buffer_samples AL_SOFT_buffer_sub_data AL_SOFTX_deferred_updates AL_SOFT_direct_channels AL_SOFT_loop_points AL_SOFT_source_latency
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: AudioRenderer supports 64 channels
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
WARNUNG: Pausing audio device not supported.
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: Audio effect extension version: 1.0
Okt 26, 2015 9:09:42 PM com.jme3.audio.openal.ALAudioRenderer initOpenAL
INFORMATION: Audio max auxilary sends: 4
Okt 26, 2015 9:09:43 PM com.jme3.app.Application handleError
SCHWERWIEGEND: Uncaught exception thrown in Thread[jME3 Main,6,main]
java.lang.IllegalStateException: Cannot find any joysticks!
at jme3test.input.TestJoystick.simpleInitApp(TestJoystick.java:49)
at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:227)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:131)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:212)
at java.lang.Thread.run(Thread.java:745)

pspeed · October 26, 2015, 8:28pm

The output from the second run looks like you ran it from the test chooser instead of running test joysticks directly. Can you confirm that you ran it directly just to be sure?

As a second test, try modifying the TestJoystick class to set the logging level as I already recommended above. You should be able to create a new test project and then modify the code there if I recall correctly.

Yves_Tanas · October 26, 2015, 8:31pm

Wohooo - Yes.
I had a small language barrier in here and running it directly - yes, that information i didn’t get since now correctly.
This is gonna be a long night, because it works, yes.
Thank you for your really huge patience with me.
I am digging back into code now :-* :-*

Ogli · October 26, 2015, 10:30pm

Okay, so we can scratch one item from the TODO list, good to know. Good for you, good for us.
Yeah, sometimes misunderstandings may happen, next time my instructions will be crystal clear.

Ogli · October 26, 2015, 10:56pm

That’s what I think too, but I’m just a humble and passive user. I don’t know how open source teams handle such a dispute (maybe you step into some stone henge circle and perform Vulcan wrestling rituals?).

At a later stage, GLFW might be good, if 3.2 can deliver correctly and all expectations are met.

It only has one advantage so far: GLFW has XInput. XInput (the new XBox-style API) is the only one that Windows Store apps will allow, no DirectInput allowed because of Windows Store rules. For what Windows Store is needed (aside from Windows Phone), I don’t know, maybe XBox consoles.
So technically, there is one thing missing in both input libs: GLFW has no DirectInput. Jinput has no XInput.

There are questions rising now, here is one:
Is it possible to get LWJGL3 without GLFW? (because that library would handle joystick input each frame and that might be some unneccessary overhead, especially for many joysticks and especially when later versions of GLFW report events too instead of joystick polling only).

Ogli · October 26, 2015, 11:15pm

That’s what we need to find out (what I’m planning to investigate). Either we are using jinput wrong or jinput itself is poorly wrapping the DirectInput rumble capabilities.

Back in 2013 when I tested rumble with jME 3.0 I might have made a mistake too. To do it right, I will need to learn from those who know what to do.

Some things that I found in 2013:

changing rumble intensity during running rumble functions could lead to crashes if the span between changes were to short
as other users in this forum remarked already: the rumble intensity feels always the same even before and after changes to the intensity

I guess we soon find out how deep that rabbit hole goes… :chimpanzee_wink:

pspeed · October 27, 2015, 12:08am

It must be… or we shouldn’t switch because the implication is that LWJGL would be horribly designed and extremely broken otherwise. If it’s not modular then that’s a good case for abandoning it completely. So my guess is that it’s like it is now and you only use the stuff you use.

And DirectInput is still the primary best way to do devices on most platforms today… and we aren’t sure where XInput fits yet. It can’t be that hard to add XInput support on its own, either as a patch to JInput or even its own stand-alone module.

To me, supporting XInput is easier than fixing the dozen things that will break if we switch from JInput.

zzuegg · October 27, 2015, 7:22am

I looked a bit into XInput, and i have a local test project working.
Integration with jme should not be a problem.

Issues:

Windows only.
XInput 1.3 for windows <= 7
XInput 1.4 for windows 8+
Windows < 7 requires VC++ 2013

Benefits:

Rumblers working

I am not sure if it is worth integrating such a library into the core to support a single OS. If its up to me, it should be a user plugin that integrates nicely. Since i have a xbox controller, i could explore further into this direction to see if some changes to the core are required to integrate nicely.

Empire_Phoenix · October 27, 2015, 7:32am

Hm if it does not prevent anything else from working, I see no real reason to not have it a (optional) module
jme-xinput-joystick or similar. Who wants it just uses it then, the rest ignores it.

But having it in core would mean that smaller api changes would be noticed directly without another roundtrick.

jakebriggs · October 27, 2015, 8:36am

You forgot another benefit - the triggers are treated as separate axes under xInput while they are treated as one axis under directinput.

I presume under linux and osx jinput shows the triggers as separate axes, since microsoft didn’t write those drivers…

I personally would like to see xinput support in some manner in windows, even if its a bit hacky, even if its unofficial.

Momoko_Fan · October 31, 2015, 5:20pm

There’s always the option using both simultaneously … E.g. by separating jME3’s JInput support into its own backend away from jme3-lwjgl.
JInput / DirectInput can be used as a fallback if the joystick cannot be detected via GLFW / XInput2.