I would not say that task is up to the core team. If someone desperately needs it, he/she should get in contact with them, and implement it following the guidlines.
Using XInput is not magic, since the java bindings already exists
I cloned this project, removed the cpp stuff and “gradlefied” it so that i can be used trough jitpack.
maven { url "https://jitpack.io" }
compile 'com.github.zzuegg:XInputDevice:e3430b0b2e'
and follow the guide on StrikerX3’s repository
Sorry for using an inexact word again:
“the jME team would need to properly integrate this into the engine - until then it’s only a hack”
That sentence was just intended to make things clear to Pesegato.
Also, it is meant in the broader sense of “if not properly integrated by someone” (which could be any dev, including Pesegato) “then there is no XInput in jME”.
I’ve also pointed out that Pesegato maybe could ask you for help and try to modify the engine via a bypass earlier and did not want to repeat any single word again. (Of course, a proper integration by any dev and then a pull request would be better) (Of course, as I pointed out, there may be some problems when using two different APIs at the same time - so this maybe is not such an easy task as one might think at first glance).
Phew… oh man… I’m really glad that I’m not a lawyer … I would terribly suck at this job! :chimpanzee_closedlaugh:
Also I did not take into consideration that many tech people very strictly and narrowly interpret any word I write and often lack the usual “soft filter” that most other people use when communicating… :chimpanzee_wink:
I wonder why the XBox 360 gamepad has such a poor support for DirectInput.
Why to make something like XInput in the first place. I don’t get this…
Embrace, extend, extinguish. Microsoft wanted people to buy their controller, so they crippled directinput support for the xbox controller. Obviously this is just a guess - I don’t work for microsoft 
To slightly derail the topic, I’d like to think “outside of the box” and express some opinion on the matter:
DirectInput was perfectly fine, but I guess they want to “standardize” it, so that all the controllers worked the same by removing features.
About requirements for user friendly games:
Input mapping configuration must be available (possibly ingame).
xbox360 controller (and xbox one controller) is a de facto standard and should work out of the box at least for the Dpad, “A” and “B” button mappings for OK/Cancel.
Steam big picture mode should play nicely with this. For example, the JME splash dialog is very useful, but assumes that we are using mouse. There should be some “gamepad navigable” version of it, or maybe it should be skipped altogether when in big picture mode.
For Mac and Linux the only option is DirectInput. But again, big picture should play nice with it.
Comments/advices?
Pesegato - I didn’t mean that microsoft crippled directinput (the api) itself, I mean that they crippled the xbox360 controller directinput driver. directinput could easily have supported two more axes. You chopped my sentence off half way through.
Also, neither linux nor mac uses directinput fO_o
Yes, any real game should turn that big ugly settings dialog off and provide their own settings options if required. It should really be on every games final-polish checklist.
Thanks for these comments. Not completely derailing, because it has to do with the importance of gaming devices in combination with jME. 
It would be nice to have a wiki page or source code repo for this standard polishing task - all jME users will want this. @Ecco recently showed a very nice ingame settings dialog. Such a dialog will appear inside jME and let you change graphics settings. Since DPAD is always the same on all joysticks / gamepads / steering wheels under DirectInput, this could be used as standard joystick input, yes (good idea, @Pesegato) together with any button of that joystick device (which one is the “any button”? :chimpanzee_wink:)
Yes, but then you have to pick a UI layer because the infrastructure necessary to support ‘joystick selecting buttons’ is a pretty huge undertaking otherwise.
For Lemur, I’m working on this. I plan to port and make more generic the stuff I used for UI settings in the latest Mythruna since it’s all in game. Joystick navigation of a Lemur UI is way higher up on my to-do list and I already have a focus manager and rough function bindings mocked up for that task.
The problem is always time.
But ultimately, things like control remapping, in-game settings, etc. will be specific to a UI toolkit and the good ones should have those available either built in or as add-ons. It’s not really something JME can support directly ‘in core’… unless Lemur someday becomes part of JME on some level.
Edit: but note, soon I really do hope to provide these things as standard Lemur components and Lemur is light-weight enough (and directly scene graph integrated) so shouldn’t be too onerous for games to use just for those features even if they have their own UI otherwise.
I figure how that wiki page about “ingame app settings dialog” could look:
First a little text explaining why the splash screen with app settings makes problems.
Then a solution with just BitmapText and standard jME input mapper for keys / joysticks.
Then for each UI toolkit (Lemur, ToneGodUI, Nifty, JFX, …) a version for mouse / keys / joysticks.
For some settings the Java executable will need to restart (e.g. windowed vs fullscreen). But that’s all details that the wiki page could answer.
The standard is using the green “A” as OK/Confirm, and the red “B” as No/Cancel/Back
I bet the steam controller will stick with this convention:
So the problem is: how to make sure that at least A and B are correctly mapped on Win+Mac+Linux? (At the very least on xbox360/one controllers, steam controllers and logitech).
No, you can design the menu in such a way that you won’t need the “back” button.
If you only have DPAD cross and “any button” then any button will work just fine. :chimpanzee_grin:
Also green and red are bad colors anyways (think of the 15 percent male humans with red-green-blindness) and not all gamepads use letters - I’ve seen some with 1,2,3,4 and with Playstation (triangle, square, circle, …).
This “which one is the any button?” was meant as a joke. Maybe you know the joke about the “any key” on the keyboard - that was a reference to this joke :chimpanzee_wink:
I think you greatly underestimate the amount of infrastructure that you’d have to implement to make such a UI with simply BitmapText… and it would look very much like Lemur’s core components. After all, that’s precisely the use-case Lemur was designed to cover. ‘Picking’ alone is a tricky enough problem that requires quite a bit of infrastructure to do properly. Now implement some checkboxes and sliders…and allow key navigation. Ugh.
Never mind that a hand-rolled approach would be totally ugly and completely stuck in a particular style.
That’s false. You can go from windows to full screen and back without restarting the JVM. I do this in Mythruna’s new engine.
Yep. Just always have a ‘back’ option and have the default mapping have every button be the ‘ok’ button.
then let the user customize what they want ‘back’ to be… though the whole idea of ‘back’ is kind of UI specific on its own and not something that can be implemented by default really.
Cool.
Yeah, just like almost all the TestXYZ.java apps. But they still work.
No, I don’t. Nothing was said about “picking” or combo boxes. Just keys and joystick and some BitmapText. Basically you need arrow up,down,left,right and [Enter] and DPAD and any button.
There is more options. You could do it like the playstation menu or some computer displays: up and down for sub menu, left and right to toggle options, button press to enter option, another button press to confirm option, standard is the option you already have.
There are several clever ways to define a UI.
“hi, developer… you can use this ugly non-mouse interactive UI to do this thing or you can include a 343k jar and have a nice stylable UI that supports mouse and touch, etc…”
I don’t even think the first option is worth implementing. I mean, are you talking about joystick mapping now or a UI settings screen? What would you even be mapping in the control mapping case? You already need infrastructure to support remapping… some kind of abstraction that JME doesn’t really provide properly. And for a settings screen, there is already the settings dialog which would be 100x better than the described monstrosity.
UI settings screen. Like I said:
The first option would be just to prove the concept. It could also be TestIngameSettings.java and just a mere weblink or reference to that .java test file.
Ah! Of course … that’s the explanation why the jinput mapping is different under Linux / Windows and why we can’t use the same joystick-mapping.properties file under both operating systems… :chimpanzee_closedlaugh: