Input Abstraction Layer

Engines, Libraries and Tools JInput
#1

Hi!

kevglass and I are writing an abstraction layer for 2d graphics. we just want to add an abstraction layer for input.
that would make it possible to have input via different libraries (jinput or awt). this is needed because we want to have a solution that is 100% platform independent.

the only solution we have found is to create a key mapper that maps awt keys and jinput key values to the same value, since jinput and awt use different values for keys. is there a better / faster solution?

troggan

#2

I’m not sure the question was really understood here.

Why don’t the axis codes for keyboard buttons in JInput match up with their associated key code in AWT?

Maybe it’s to do with it being a more direct mapping to the keyboard in JInput, just wondering if someone could enlighten us?

Kev

#3

Maybe you just take the JXInput approach?

#4

Its entirely possible at this point. More worried about gamepads more than anything else tbh.

Kev

#5

JXInput covers gamepads easily. If its more about buttons, the JXInput eventing might be usefull. Or its button-combis constructs…

#6

jxinput is not free if you want to sell anything that uses it.

#7

Thats written nowhere. So far, everybody interested received a free license.

I currently considering putting it under a opensource licence. I just have no idea how to…

#8

Jinput will also work ok with gamepads, just ignore the keyboard and mouse stuff, you get alot more platform independance. Last time I checked JXinput didn’t have linux or mac versions, just the ability to have ports/plugins.

HTH

Endolf

#9

Thats not really a solution I’m happy to play at the moment. If the user has gone to the trouble of distributing jinput with their stuff then they should be able to utilise its pollable nature. Implementing JInput support but then using AWT to pick up mouse and keyboard would be a last ditch I reakon.

Kev

#10

I think i missed the point somewhere near the top of this thread. The original question was about having inputthat is platform independant. The closest you will get is using jinput for the platfroms it supports, and awt for the rest, the rest will only have mouse and keyboard support. Then there was a question about the key codes. If you want awt and jinput then you will have to map the key codes. If you want gamepad support on windows only then you can use jxinput, but at the last look itdidn’t have any implementation for mac or linux.

jinput is closer to the hardware, and has no idea of the key codes based on the keyboard layout you have, which sucks. I think for my projects i’ll end up writing a wrapper around awt mouse and keyboard and create a pollable interface over the top, then use jinput for gamepads/joysticks. It’s not ideal, but nor is jinput or jxinput or awt alone.

Endolf

#11

Ok, I think we’ve talked about this before (offline) but if JInput sucks for keyboard then wouldn’t it be nice to supply an AWTKeyboard device that just wrapped the pollable interface around the AWT events as part of JInput?

The original question was really only about keyboard and the lack of common values between JInput and AWT (which you’ve just explained).

Kev

#12

[quote]Ok, I think we’ve talked about this before (offline) but if JInput sucks for keyboard then wouldn’t it be nice to supply an AWTKeyboard device that just wrapped the pollable interface around the AWT events as part of JInput?
[/quote]
Yes. I’ll try and get en environment working on my laptop when I get back and look into it. It’s a good idea that I hadn’t thought of before. My initial thoughts are that it would show up as another device when you do a getControllers on your environment. I’ll talk to jeff nad see what he thinks about it. If I get the go ahead i’ll get on wit hit, if I don’t then I’ll probably work around it and get something that sits over ‘official’ jinput and returns everything + the new controller and release it, as I think it’s how most people will want to use it. I might look and see if it makes sence to wrap the mouse too or not.

Cheers

Endolf

#13

The issue with using AWT to read keyboard and mouse basically boils down to this:

JInput is designed purposefully to be AWT independant. This is so you don’t have to drag the huge AWT tangle of classes into memory just to do input.

That being said, you could indeed write an AWT based plug-in that hid the AWT details for when you want that. It woudl be kind of nice to have one gauranteed way to get mosue and keybaord on any J2SE system (note that J2ME systems don’t support full AWT though so your back where youstarted from there.)

The biggest issue with writing this plug-in is that, to function, it needs an AWT frame passed to it. You will only get input within the scope of that Frame.

As I do not want to expose AWT-ness in the API, what you will need to do is somethign like this in the initialization section of your client code:


if (myDeviceContext instanceof AwtContext){
       ((AwtContext)myDeviceContext).setFrame(myFrame);
}
#14

Hi
The way I had thought of doing this was to be completetly optional, so a user can ask the jinput environment to create it an AWTKeyboardDevice, passing a component to it, thus if you are not on an AWT enabled device it will not worry you, but if you want it it is there. This might introduce compile time issues though for the platfroms that don’t have AWT. Maybe a layer over the top that isn’t part of core jinput would be the way to go, but making the layer onto look like jinput, and create the AWT devices if requested on a per component bases.

Thoughts/comments/rotten fruit? :slight_smile:

Endolf

#15

Hm.
You mean add a new API call to get this AWTInputDevice?

The problem I see there is that yo ueither need to make the parameter a Component, which pulls in AWT immediately as now you are referencing the AWT class tree, OR pass a generic "Object’ through. Which is pretty ugly when all you really want is a component and anything else is an invalid parameter.

It still seems cleanest to me to do it by downcasting a DeviceContext supplied by an “AWT Plugin”…

#16

Hi
I can see where you are comming from on this one, I guess setting a property up and then checking it to say wether or not to load the AWT plugin too, but the way I see it you would want both the awt plugin and the native one, so that you still have access to gamepads etc.

More thought required, I’ll look at this next week if I can get jinput up and building and running on my laptop on sunday.

Cheers

Endolf

#17

You could register for key events on a global scale using:

Toolkit.getDefaultToolkit().addAWTEventListener(myKeyHandler,AWTEvent.KEY_EVENT_MASK);

and hence not ever have to have an AWT component. Also this means that at runtime you wouldn’t need AWT unless you hit this bit of code (at which point you must have requested the AWT Keyboard) at least thats how I would think dynamic binding would work.

Kev

PS. Thanks to someone over in the Xith3D forum some time back for this tit-bit.

#18

Cool. That relieves the component issue for the Keyboard, is there a similar way to register a mouse listener?

#19

If you look into the AWTEvent Class, there are much more Event Masks, just try this one : MOUSE_EVENT_MASK

troggan

#20

[quote]You could register for key events on a global scale using:

Toolkit.getDefaultToolkit().addAWTEventListener(myKeyHandler,AWTEvent.KEY_EVENT_MASK);
[/quote]
Well that makes things a little easier :slight_smile:

Back to asking the environment for an awt keyboard device or a awt mouse device then Jeff?, or how do you want to take this further?

Cheers

Endolf