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?

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.

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.

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.

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).

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?

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.

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:

1 2 3

if (myDeviceContextinstanceofAwtContext){ ((AwtContext)myDeviceContext).setFrame(myFrame);}

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

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"...

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org