OSX Update

Engines, Libraries and Tools JInput
#1

'MKay. I’ve started checking in stuff for the OSX release and plan to have a running build before the end of the weekend. Currently I have checked in native code that enumerates the input devices and prints their capabilities to the console.

Next step is to map these funky HID hexcodes into features that JInput uses. For now I have to let it be known that I am intentionally mapping AROUND the mouse, because nothing is more annoying that losing control of the mouse while developing :slight_smile: It DOES get enumerated - you just can’t use it yet. It will likely be the last device I support … unless tomorrow’s release is a lot more stable.

#2

Jeff, if you have the ability to get some OSX gamepads and the like - drop me a line :slight_smile:

#3

I will be testing with a Macally iShock II USB force feedback game controller on a 1GHz TiBook. Just in case you want to purchase something different to get more coverage of available devices.

#4

I have a Logitech Wheel I can test with, I think. It’s designed for the PS2 and games like Gran Tursimo but I’m told it works on the PC and I’m gonna assume OS X.

The wheel has a good number of buttons and foot pedals and force feedback and rumble feature.

#5

Was just able to confirm with Scott that at the moment the native library can at the very least find all of the devices that are attached to your machine using HID and return information about them to Java. One of the hardest parts of the binding is apparently behind us.

Now to cobble together some time to finish and get the rest of the integration done. The OSX port is a little bit different from the DX8 port in that the binding code is a little more isolated. JInput calls the binding JNIWrapper. I did this mostly to give the LWJGL folks the ability to integrate with native OSX input without having to deal with JInput directly.

#6

Started on the actal JInput integration. Since I’m following the same code path that the DX8 route went for portability I’m not going to be able to have a binding within a binding so the LWJGL folks will just have to take a look at the source and port from the available JInput source. I’ll keep it as separable as possible though.

#7

The latest JNIWrapper class and native library are located at my blog site as indicated below.

Things are coming along swimmingly. At the moment you can query all the devices, open and close them from the Java interface, and get the devices capabilities from the device (kinda sorta mostly).

The final step is coming much faster than I anticipated - polling with the devices and moving data from the queues that the OSX HID Manager maintains to the Java layer so that developers can determine what it means/what they want to do with it. I’m not going to get into keymaps, redefining keys and what not - you’re big boys :slight_smile: The HID manager pretty much treats the keyboard as one big-ass gamepad with each key having a min/max of 0/1 and you’ll be able to get buffered keyboard state from it… in fact you won’t have any choice as all input in the OSX system will be buffered whether you want it that way or not (because that’s how the HID API works).

Feels good to almost be through with this piece so that I can move on to OpenAL (ugh I hate that API), and then come back and start doing some serious smackdown on JOGL itself.

#8

Note, if you want to try it out - just download the files and run the main method of JNIWrapper (for now).

#9

dude its strange (not looked at input stuff in an age). wooo its great stuff. works tip top fine here on my TiBook. going to find a very odd controller around the office here (we make the odd bit of hardware). and give that a try :slight_smile:

nice job!

#10

I now have a release of the OSX build polling devices into queues and the Java side being able to pull data from those input queues. Apple does something funky with defining event types on the queues however so I need to sort through this before I can do a release. Seems you tell a queue which keys/buttons whose events you want to show up on the queue, which while interesting just seems horribly wrong somehow. It should just get events from the device and add them to the queue, not require that I tell it I want events for button/key/axis/etc. Once this gets sorted out this weekend I’ll have something nearing a final release of JInput for OSX.

I need to talk to an Apple dev and find out what they were thinking when they designed this subsystem. Once I can mindmeld with that person(s) I can wrap things up.

#11

Hmm. sounds similar to the Amiga event system. It has advantages. By only getting events that you actually care about a thread that is waiting on an event won’t wake up and cause a context switch only to decide that it really has nothing to do. E.g. why send every single mouse move to a program that doesn’t use the mouse?

I’m not sure if what you are saying works the same way, but in any case it shouldn’t be too hard to work around.

#12

Is it reasonably easy to work around - kinda. Its really a pain in the ass because that means that I have to go and essentially set up listeners for every key, axis, etc on every device as that’s where the data comes from.

Its not similar to your example, because a program that doesn’t use the mouse would not open the mouse. But having a program that uses the mouse go in and add events for every wheel, button, and axis is just stupid from an API perspective. No good ever comes of that. This is a good example of a piece of API that is over designed.

#13

Hey Guys,

My apologies on being gone a few days… STILL dealing with moving the last of my stuff and emptying my house.

Greg, yeah I can get you a USB pad pretty easy. Email me at jeffrey.kesselman@sun.com with snail mail details and Ill try to post you something next week.

Terrific going on the OSX stuff. I need to update the Win32 mouse as it has been pointed out to me that it could be more useful if it returned non-normalized data. (I inherited the code thats there, actually.) We probably want to come up with an agreement on what mice return so its the same across all plug-ins.

Thanks for all the effort on this.

JK

#14

Okay I’ve taken a look at those bugs and I can address some of them. The special keys don’t get mapped because JInput doesn’t have a Key binding for them. The binding knows about them and is listening to them, but there is no call from JInput that will ever get information from them.

Page Up is mapped to 0x4B (no mapping)
Page Down is mapped to 0x4E (no mapping)
Forward slash \ is mapped to 0x64 in HID (no mapping)

Not sure what’s going on with the down arrow as it is mapped properly. I’ll check it on a regular keyboard and see what happens.

I suspect that there may be some keycodes on the Powerbook keyboard that are different than the standard ones. I’ll take a look at it tonight because all of the metas are mapped properly so I’m truly surprised they aren’t getting reported properly.

#15

[quote]Forward slash \ is mapped to 0x64 in HID (no mapping)
[/quote]
Psssst… thats a backslash.

The missing keys need to be added to JInput then. PgUp/PgDn aren’t all that special nor is backslash. Things like eject and volume adjustments are in a different category so if they are missing nobody is likely to care.

Actually… what about those fancy multimedia keyboards with volume, play, stop, FF, rewind, email, browse, scroll wheels etc… They are fairly popular now.

#16

With Logitech iTouch keyboard:
During enumeration…

java.lang.NullPointerException
at net.java.games.input.OSXEnvironmentPlugin.addControllerElement(OSXEnvironmentPlugin.java:432)
at net.java.games.input.OSXEnvironmentPlugin.enumDevices(Native Method)
at net.java.games.input.OSXEnvironmentPlugin.(OSXEnvironmentPlugin.java:335)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:306)
at java.lang.Class.newInstance(Class.java:259)
at net.java.games.input.DefaultControllerEnvironment.scanControllersAt(DefaultControllerEnvironment.java:183)
at net.java.games.input.DefaultControllerEnvironment.scanControllers(DefaultControllerEnvironment.java:164)
at net.java.games.input.DefaultControllerEnvironment.access$000(DefaultControllerEnvironment.java:57)
at net.java.games.input.DefaultControllerEnvironment$1.run(DefaultControllerEnvironment.java:108)
at java.security.AccessController.doPrivileged(Native Method)
at net.java.games.input.DefaultControllerEnvironment.getControllers(DefaultControllerEnvironment.java:106)
at net.java.games.input.test.ControllerReadTest.(ControllerReadTest.java:239)
at net.java.games.input.test.ControllerReadTest.main(ControllerReadTest.java:288)

#17

This is unfortunately Logitech’s fault as the Logitech keyboard defines itself as TWO HID devices as opposed to one device with two sub devices. All I can do is put in a wrapper to have it throw out the device if it can’t identify it as a keyboard, mouse, gamepad, joystick. The iTouch tries to show its USB hub as an input device - which clearly it isn’t.

#18

Hey Guys.

We are just finishign up gettign automated build of Win32 workign and will likely start working on autobuild for OSX soon…

Which leads me to this question: do you have a build.xml hiding somewhere for the OSX plug-in?

#19

I made some changes to the main build.xml and created some for the OS X specifics. I gave them to GP, since I haven’t yet managed to remember to send in the paperwork to get a developer role… I only have the time to do small things like the build file anyway, but I figure I should probably sign up as every little bit helps.
If I’m lucky I will have a chance to become more familiar with JInput and the OS X input APIs so I can assist with the gamepad integration. But chances are GP will have a gamepad device to test with before I get that far.

#20

Yep, thanks to Jeff and the fine folks at Sun I have a controller which I will plug into my Mac when I get home and hack away at gamepad integration. The gamepad should be as easy as the mouse was. Its the keyboard that’s a PITA.