I have been trying to test JInput lately. I downloaded the latest lib/bin, compiled and ran the tests programs.
On my config (WinXP, athlon, no joystick) I was expecting to see a mouse and keyboard in the list of controllers but I get nothing. I wrote some code also to list the controllers and I get nothing.
So I tried the webstart based test at newdawnsoftware and I see my controllers.
I guess I must be trying to do something stupid. Also I am confused about why there are several libs with the same name in both coreAPI and plugins (which ones should be used ?). What is the difference between these libraries.
It sounds like the controller plugin for windows is not in the correct spot. It’s been a while… but I think you typically need to put it in a ‘controllers’ folder. I’m sure it is in the readme somewhere.
I think its “controller” without the “s”, but yep. Or you can use the funky new property to override the whole thing which I assume documentation has been added for?
Kev
Hi
The builds do seem a little funny. What you need as jutils.jar and jinput.jar on your classpath, the directory called controllers with (for directx) dxinput.dll and dxinput.jar in it, the dir above controllers on your classpath
ie.
cwd contains
jinput.jar
jutils.jar
controller\dxinput.dll
controller\dxinput.jar
and you should be able to just run it with
java -cp .;jutils.jar;jinput.jar net.java.games.input.test.ControllerReadTest
HTH
Endolf
[quote]Or you can use the funky new property to override the whole thing which I assume documentation has been added for?
[/quote]
Documenwho? 
-Djinput.plugins=<pathtodxinput.jar>
i’m guessing (i’ve not tried it) that with this approach you will need to set up your java.library.path yourself to include wherever the native dll/so is
Cheers
Endolf
Thanks, but no luck so far. I will do more tests later.
To say the least the packaging is ‘creative’: when I install JInput from the zip file, I get
jinput.jat both under coreAPI/bin and plugin/DX8/lib
jutils.jar both under coreAPI/lib and plugin/DX8/lib
dxinput.dll is both under coreAPI/src/tests/controller and plugin/DX8/bin
dxinput.jar is both under coreAPI/src/tests/controller and plugin/DX8/bin
So far, I did not know I needed to include the controller dir under tests or create a controller directory.
I created a jinput dir in my working dir and put jutils.jar and jinput.jar in there. Then I created a controller dir under jinput and copied dxinput.jar and dxinput.dll in there.
Then I tried to run my test (if it basically a wrapper around ControllerReadTest)
java -cp .;./jinput;./jinput/jinput.jar;./jinput/jutils.jar;./test/classes;./classes test.testJInput
Same result: no error but only 1 empty window because no controller is detected.
You need to move your controller directory up one so its level with where you’re running from.
The packaging and layout is bizarre but I’d always just assumed there was a good reason
Kev
You nailed it guys !
When I copy the controller directory to the level I am running from, it works (and only in this case).
I had no luck with -Djinput.plugins (any “:” in the path makes the program fail with class not found or something).
I don’t know about you but I think it is a weird behavior and I do not see the rationale so far. Any user running a program using JInput needs to copy the controller dir to the installation dir ?
Thanks anyway.
The controller dir can also be placed in a more permanent spot like JRE\LIB\EXT I think… but otherwise it is jsut a subdir of your game folder… not that strange.
jinput.plugins isn’t a list of paths, its a list of environment classes to instance at startup.
So if you put dxinput.jar in your classpath, dxinput.dll in the same location as any other native jars (or at the location you’re running from) and set jinput.plugins to:
net.java.games.input.DirectInputEnvironmentPlugin
Then you’ve explicitly told JInput to use that plugin. Its especially useful for webstart.
Kev
Yep
The original design intent was to provide 2 places to put the plugins.
(1) In a place where all clients of a jre could use it (AIR thats jre/lib/ext/controller)
(2) In a place that could be game specific (the controller dir youa re using.)
This way JInput could be installed either as a part of the game, or as a JRE extension. The rationale here was that a game may want to insure a version, or may have game-specific plug-ins it wants to add.
The other ways were added in order to make webstarting convenient.
Hi
Newbie myself, I think the info in this thread is valuable! (made an environment tool out of jinput with a script to add all whan I wanted to ‘pollute’ the classpath etc. when I wanted to use it. This didn’t work as the controller dir was not located under my start dir)
thanks!
/aksel