Hybrid Input Abstraction Layer (HIAL)

Shared Code
#1

Hi,

I have created an input abstraction API.

It provides interfaces to hardware to remove dependancies on any one input API (currently AWT and LWJGL implementations are provided out of the box). It also allows input to be converted from one processing style to another (hence the “hybrid”). For example, you can use LWJGL-like keyboard state array query polling with AWT.

The time penalty for using this API as opposed to AWT or LWJGL directly is near zero (this is due to all critical methods being O(1) complexity and with zero garbage generation)*.

I created it for two reasons. Firstly is to provide an abstraction layer from the hardware devices. I need this now that Xith3D supports LWJGL, and it also future proofs my code as I may again wish to switch input API’s. The second is to provide handy processing of keyboard inputs with the concept of “sticky” keys. Prior to developing HIAL, I used a custom solution (which I previously wrote an article about). HIAL provides this concept and expands it to alternative input processing (like key state arrays) which are faster again.

As a result of some tireless hours spent documenting: The API even has complete javadocs!

You can read more about it, look at examples, view the javadoc and download the code here: http://input.jtank.net.

I have released it under a BSD-like license.

Regards,

Will.

  • Conditions apply, one method does not follow this rule (but you don’t have to use it).
#2

Hm, could be made a JXInput driver :slight_smile:

#3

and vice versa. I have yet to add joystick support to HIAL but it is on the list.

May I make a suggestion?
It would be good if you liked to: http://www.hardcode.de/us/index.html from here: http://sourceforge.net/projects/drts . I followed the sourceforge link in your sig but couldn’t find any info on JXInput (I had to google in the end).

I take it you can access DirectInput controllers though JXInput, is that correct?

Will.

#4

Great. I’ll look into it. Do you have to keep track of the mouse button state yourself as there seems to be no methods for asking the current state when for example getting a newX() event? ???

#5

Not in the listener interface itself there isn’t, but you can use the pre-fabricated MouseListner implementing MouseMotionAccumulator which does keep track of the X and Y values.

Will.

#6

[quote]Not in the listener interface itself there isn’t, but you can use the pre-fabricated MouseListner implementing MouseMotionAccumulator which does keep track of the X and Y values.

Will.
[/quote]
Oh, missed that one. So, if I’m interested in state and notification I should create a listener that extends MouseMotionAccumulator? Will that not result in keeping unnecessary duplicated states around?

#7

You have two options:

a) extend MouseMotionAccumulator, and override the events you need to (make sure you remember to call the super method if you still want MMA to process the event).

b) create your own listener, and add it to the device. The device will send events to both listeners. The overhead for doing this is minimal (these are O(1) methods we are talking about).

Cheers,

Will.

#8

[quote]and vice versa. I have yet to add joystick support to HIAL but it is on the list.

May I make a suggestion?
It would be good if you liked to: http://www.hardcode.de/us/index.html from here: http://sourceforge.net/projects/drts . I followed the sourceforge link in your sig but couldn’t find any info on JXInput (I had to google in the end).
[/quote]
Yeah … DRTS needs a page of its own anyway. I fooled around with some CMS where an own JXInput section could belong, but without success to far. Volunteers?

Correct. Thus JXInput has parts on the same level as HIAL and other parts that are much more high-level (e.g. simulating joystick axes with keys or mouse, treating mouse or keyboard like joystick buttons and so on, providing event vs. polling etc…

#9

But if I add two listeners do you guarantee in which order they are called? The MMA listener must be called before my other listener, otherwise I can’t trust the state it reports.

#10

It isn’t documented as such, but it can be.

Currently all Devices use a common abstract class for the broadcasting which uses an ArrayList. The listeners are called in the order they were added.

Will.

#11

An easier alternative would be to store the state in the MouseDevice. What is the reason for not doing that?

#12

The devices should not store any public data – they send events to listeners which do.

What exactly do you need? I am a little unclear.

Will.

#13

Good luck with the Volunteers. I tried that for xith3d – everyone was happy to complain but nobody wanted to help. I guess most of us are programmers not web developers.

I do recommend tikiwiki though, I use it for Xith3D and Odejava and it’s pretty good.

thanks for the info.

Will.

#14

It’s I who is a bit unclear. :slight_smile:

Basicly what I need is to get the mouse position when a button is pressed or released, and the mouse button state when the mouse is moved (for dragging). I think this is very common. For example in AWT you get a MouseEvent which contains all this information. In your case maybe you don’t want to create a mouse event, you could keep the info in the MouseDevice class instead (getX(), getY(), isButtonDown() etc.), similar to the LWJGL Mouse class.

Just a suggestion. I could create my own wrapper for your library that does this, but maybe it would be better if it was included in your library.

#15

Using MouseMotionAccumulator you can:


boolean getButtonState(int)
int getX()
int getY()

EDIT: This data is stored in the implementation of the listener. The Devices should not expose any data at all. One may only call “update()” on a device, that is all. The device should handle the rest and notice the listeners of all events. It is up to the Listener implementations to handle use cases such as yours.

I notice in the docs it says “Button presses are ignored by this MouseListener”. This is out of date, it does now.

Will.

#16

You’ll want to be very careful about JXInput. It has a license that is incompatible with open source licenses. We had JXInput capabilities in Xj3D for a couple of years but never publically shipped it because of this reason. The maintainer was not interested in changing the license either.

#17

Has it changed since then? From the look of this page: http://sourceforge.net/projects/drts it is BSD licensed.

Will.