A friend of mine has made some comments about how choppy some of my demos run because of the bad combination that is AWT events and JoGL rendering.
So I was thinking about using JInput and ditch AWT for keyboard and mouse interaction.
Question is, are the binaries for Mac, Win and Linux mature and stable enough?
Is it worth making the complete switch to Jinput over AWT?
We are just settling some issues to work towards a 1.0 release.
If you build the latest from CVS it is decent. Mouse input seems to be working fine, but you may be a bogus report of 2 buttons on a Mac that really only has one button. Keyboard support is finally worked well on the Mac, but key names on the Mac are bogus “Key 34” instead of something like ‘W’, ‘Z’, etc…
Gamepad support on Mac is coming soon… if I can figure out some HID stuff before G.P. gets to it that is 
By all means try it and report any problems… best they get worked out prior to 1.0.
I have a mac guy now whose offered to help us. Im going tos end him the KB and tarck pad issues tomorrow.
Tell him to look at the “HID keyboard input” thread on Apple’s mac-games-dev mailing list… I posted the issue there and got some good feedback.
Problem is, I can’t get the thing to work even if the sample code that I have compiles.
I tried placing the dxinput dll file into various places with D:\JDK\jre\bin being the standard path where I usually place all my dlls (JoGL, OpenAL, LWJGL etc…), and yet I always get 0 devices …
The JAR and DLL for the controller should go in a ‘controller’ folder where you run the app from.
If you are using webstart - look at the examples in the threads here. I think they are working. (I can’t remember if I had jinput installed as an extension when I tried them last.)
This is why we need a manual. Honestly, Im working on it!
Actually we need
mouse=Envirenment.getDefaultMouse();
if(mouse.button[1]=1)…
and
…
up=mouse.wheel
…
mouse.update() //optional operation.
And get rid of than ugly ./controler folder. It took me 4 hours to get everything straight, and I was forced to read comment in the documentation.
Is something wrong with attempt to seek in the application directory?
Sixth button on my mouse doesn’t work in Jinput.
Recommendation: merge it with LWJGL, and create few different interfaces to make everyone happy.
On most of this I am not following you. the APi is purpsoefully generic to allow the discovery of arbitrary devices. You are certainly free to buidl mroe specific interfaces on top of it that meet your needs.
There is a -D flag for setting a directory to find the controllers in. Its been mentioend ehre multipel times and I also suspect its in the java docs. (yes Endolf?)
LWJGL in fact has its own input system which is already merged with it. if thats important to you you might want to look at that. When we desigedn this API we felt it was an important design goal specifically not to needlessly tie this functionality to any other such that it could be used with any other technologies you chose to.
Thats the same reason it is not tied to AWT, even though that makes writing virtul drivers a bit trickier.
But thanks for the suggestions ;D
Or was this all an April 1 gag? Sorry, took my reading that bit about your 6th button twice for that to occur to me 
[quote]There is a -D flag for setting a directory to find the controllers in. Its been mentioend ehre multipel times and I also suspect its in the java docs. (yes Endolf?)
[/quote]
/me doubts it’s documented yet :
I’ll have a poke sunday maybe, i’ve got some other stuff I want to do to the linux one so I might do the javadoc then.
Endolf
Ok
There is some bad documentation on the three properties in the package.html now, so new javadoc is needed for people to read it. It just says
Use -D jinput.plugins (or net.java.games.input.plugins) and specifiy a list of class name to over ride the plugins system. This will force the classes passed to be loaded first, then plugins will be searched for in the default manner (./controller/*.jar)
Use -D jinput.controllerPluginPath to change the path the plugins mechanism will use to search for plugin Jars.
Hope thats a start.
Cheers
Endolf
[quote]Or was this all an April 1 gag? Sorry, took my reading that bit about your 6th button twice for that to occur to me
[/quote]
I have six button mouse. And I actually seen mouse with two mouse wheels, alas not for USB.
How would JInput handle mouse with four way mouse wheel? (I don’t have this one, it was too expensive.)
And what about 10 button mouse?
really it all depends on what the OS tells us it is.
My guess is that the OS would either tell us its a generic input device or wouls tell us its a normal mouse plus some additional input device with the unusual controls on it.
But at the end it really all comes dwon to how these thinsga re reported up by the OS layer (DirectInput on Win32, HID manager on OSX.)
Hi
Under both windows and Linux it can cope with one wheel, but up to (if memory serves) 7 buttons. This is just for mice, and is down to the codes used for each part, on any other device there is no coded limit.
HTH
Endolf
looks like JInput is sometimes “over”-mature
http://www.inf.fu-berlin.de/~rschuste/java/pc-speaker.png
@endolf:
I knew you said that this would be possible so I used my last kernel uprade to see whether you said the truth.
I wonder why my scanner is not showing up in this list? Yeah, I know this is senseless but … my scanner has 3 buttons … Is there any way to have let this device show up as an event device?
If there is a device node created and useable in /dev/input then it should already be picked up, if there is no device node there, then it’s not possible.
HTH
Endolf