Controllers

[Endolf]

That just about sums it up, yup

Everyones a winner

(Including me as it means jME gets joystick support on things other than winblows )

[kevglass]

Ooer, could JInput be build into static libs aswell as dynamic? I presume thats not to difficult? Then instead of building all the code in LWJGL could simply build against the libs?

Kev

[Endolf]

No idea on mac, but certainly on linux and win32 it's just changing the args to g++. I'd add another ant target, that non of the scripts call, but could be called to create them, that way they arn't done for jinput noobs, but your average dev could work out how to build them.

Endolf

[elias]

This is very interesting. One thing left though - does the mingw requirement also comes with a requirement of a mingw runtime library at the user? And if yes, how large is that?

- elias

[kevglass]

Don't think so, at least I didn't ship it with Martian Madness and that seemed to work happily

Kev

[elias]

I'm wondering whether we really want to create a LWJGL wrapper. Is JInput really so complex that we can't just ship it "embedded" in the LWJGL native library and jar?

- elias

[kevglass]

From talking to Endolf today I get the feeling its come on a bit since I last tried. Although I still think some utility functions could be provided (like being able to detect the next input recieved for control configuration). However, I suspect these could do with being added to JInput generally.

EDIT: Also at the moment JInput is dependant of the plugin mechanism (i.e. you specify with plugin is going to be used by dropping it in a particular location in the file system). I don't really think this fits LWJGL. In addition, for gamepad support, which I'm assuming is all thats wanted here, there would be no need for this plugin nature. On windows you'd want one plugin, on Linux another and MacOS another. No need for multiple plugins on multiple environments. This could all be preconfigured in LWJGL preventing the developer having to worry about it.

Kev

[elias]

But apart from the configuration of plugins (which could probably be defaulted in the LWJGL package distribution), how complex is the actual JInput API? Too complex for LWJGL? and if no, what can be simplified such that most controllers are still fully supported (PS2 controllers, Joysticks, Wheels and whatnot).

- elias

[kevglass]

Its not really that complicated, but its easy for me to say that, I've used it before. Theres a slight difference in that buttons are treated as Axis (which I think might confuse a few people) and that there are method named relating to particular Axis. You say getAxis(int AxisType) not getRX(). Neither of these things are particularly hard to understand but both are slightly less as intuitive as LWJGL's current Controller.

Kev

[aldacron]

This is very interesting. One thing left though - does the mingw requirement also comes with a requirement of a mingw runtime library at the user? And if yes, how large is that?

MingW compiles against the MSVCRT, so nothing beyond that is needed.

[Endolf]

does the mingw requirement also comes with a requirement of a mingw runtime library at the user?

No, it's just the build environent, ming includes g++ on a win32 platform, and has the libs required to build directx stuff with g++, after that, you only need the binary it creates and the directx runtimes (the standard ones that everyone already has).

Endolf

[Endolf]

Its not really that complicated, but its easy for me to say that, I've used it before. Theres a slight difference in that buttons are treated as Axis (which I think might confuse a few people) and that there are method named relating to particular Axis. You say getAxis(int AxisType) not getRX(). Neither of these things are particularly hard to understand but both are slightly less as intuitive as LWJGL's current Controller.

The Axis object has been renamed, controllers are made up of components, a component is a key (for keyboards), a button (gamepads, joysticks) or an axis, as in throttle/POV hat etc. To get the list of controllers you call DefaultEnvironment.getControllers() (or something like that) and it returns a Controller[] you then can call getType() on those and it will return Controller.GAMEPAD or Controller.MOUSE etc, you can then do a getComponent(Component.Identifier) which are a bunch of static defined id's, like Component.Identifier.Button.START or Component.Identifier.Axis.THROTTLE and it will return one if it has it, or, you can call getComponents() and it will return them all, and you can then query them.

The plugin system is the biggest downfall in terms of usability (I think), but I have a solution that allows it to still be used, but also to be defaulted if wanted (like in LWJGL).

Endolf

[elias]

What happens if I disconnect a joystick? Is the application notified?

- elias

[Endolf]

There is a system in there to allow for that yes. Currently, when you call poll on the device, it will return non zero indicating an error, but there is a listener interface that is unimplemented so far that is designed for exactly this purpose.

Endolf

[kevglass]

Theres a slight problem with the Button.START type thing. One of my joypads for instance doesn't identify its buttons in any other way than "BUTTON15" and "BUTTON1". Is there anyway that JInput (or anything else) could tell that its a start button?

If not then I'd have to basically rule out ever using the identifiers since they couldn't be consistantly assumed... hmmm maybe as defaults or something?

EDIT: Also interestingly, I tried the JInput webstart demo with my PS1 controller and although it detects the named buttons (BUTTON1 etc..) it doesn't actually detect them being used.

Kev