LWJGL Input

[kevglass]

Hey all,

I've just got through the first interation of wrapping JInput in a tidy little wrapper for use as the LWJGL controller input layer (should people agree).

You can find a bunch of stuff here: http://www.cokeandcode.com/lwjglinput

I'd appreciate any reports or working/failing hardware and, if you have time, comments on the proposed api (in the src package).

The webstart test is known to work on windows (with DX8+). Linux and macos are currently untested though the JInput binaries have been reported to be working to at least some extent on all platforms.

Cheers,

Kev

[oNyx]

win2k/dx9c/lwjgl 0.97.1 - everything works nice (just for the log).

In order to prevent some unnecessary typing work...
-the package name is going to be changed from org.lwjgl.controllers to org.lwjgl.input
-there is a small bug with the axes... if they are centered they still report the previous value (this bug's reason has been already identified)
-a setDeadZone method is missing

Those 3 issues will be fixed this evening (so I've been told).

edit: but you guys should try it anyways (now)... maybe there is something else wrong

[oNyx]

axis[0] is y and axis[1] is x... I guessed that it's the other way around. Is it always like this? (If you run the test you can see the order... eg I get "Y Axis" first and "X Axis" right below that).

[kevglass]

Now, I'd wondered about that. Its Z,Y,X on my controller. There is actually a "type" of Axis exposed from JInput. I hid it because I thought it was just a complication but we could maybe expose it aswell?

The type is X,Y,Z,RX,RY,RZ etc..

Kev

[kevglass]

After a brief conversation on IRC,

Since the axis come back at different indices, we could have:

Controller.getXAxisValue();
Controller.getYAxisValue();

Controller.getAxisType(int index);
Controller.getAxisValue(int index);

Most of the time, if you're using an axis its going to be X or Y, for which you can use the simple methods. If not then you can determine what ever you like from the axis type and use the absolute index to get the value.

Thoughts?

Kev

[kevglass]

New version uploaded. Everything we talked about except getAxisType() since it would mean mapping what is a whole bunch of types through to some other format. Doesn't seem much point seeing as no one will ever use them.

Kev

[kevglass]

Ok, I've been asked to add two more named Axis Z and RZ which seem to be the second stick on most joypads (read the 4 that I've seen tested). I'll happily add these but should just add methods for every possible axis instead? I'd rather not, it would just lead to a bulky ugly interface but its a possibilty.

I'll add the two extra named axis tonight if no-one objects by then. Going to add checking for library loading failure aswell. I'm also intended to put a quick HTML guide on using the API together.

Any comments?

Kev

[Orangy Tang]

Axis Z and RZ were the second stick on my pad back when I was trying things out, and would be much appreciated. Additional analog axies probably won't get used much, but it would be nice to have access to them all the same.

[kevglass]

Sorry, bit confused, analogue axis are currently exposed, i.e. getXAxisValue() returns a float from -1.0 to 1.0. Have I missed a bit chunk of the picture?

Kev

[Orangy Tang]

Sorry, I meant the analog axies RX and RY. I've found they tend to get mapped to analog sliders or buttons rather than extra sticks.

[kevglass]

Ok, X,Y,Z and RX,RY,RZ are named axis. I've also added a catch all for faults on starting JInput to prevent any mishaps. Controllers.create() now throws LWJGLException should anything go wrong with JInput.

Same place, 1_0_3.

Kev

[oNyx]

Some internal bits..

1. axesMax stuff. Does it ever happen that an axis reports something > 1.0? (Dunno... well, it doesn't hurt either way.)

2. dead zones and the very slow bits... say the deadzone is 0.2... then I would get 0 until 0.2 is reached and then I would get 0.2 instantly. I wonder if that's the best way to do it, because all those very low inputs are just cut off.

You could for example normalize within that new range [0.2-1.0]... so if you get 0.2 from the controller, 0.0 is reported back. And 0.6 would mean 0.5 and so on. (Beware division by zero.)


x=actual value
y=read

1. deadzone=0
2. deadzone=~0.2
3. deadzone=~0.2 ("re-normalized")

That makes sense, doesn't it?

[oNyx]

Good news.

That hybrid pad issue dissapeared. If you actually use getXAxisValue() and getYAxisValue instead of getAxisValue(int index), flipping between the dpad and the first stick works perfectly fine. *phew*

Now we only need to check if your pad (with the "button dpad") behaves the same. I suggest adding getXAxisValue etc to the test application.

[Orangy Tang]

Shouldn't deadzone stuff be a seperate layer ontop of the raw controller data? People tend to use different ways of handing the dead zone and acceleration so this needs to be fairly customisable.

[kevglass]

Dead zone setting or Dead zone response?

Input isn't joining the core LWJGL until JInput decide what they're doing about regular native builds.

Kev