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
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 ;)
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).
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
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
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
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
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.
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
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.
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
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.)
(http://kaioa.com/k/dzcut.png)
x=actual value
y=read
1. deadzone=0
2. deadzone=~0.2
3. deadzone=~0.2 ("re-normalized")
That makes sense, doesn't it?
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* :D
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.
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.
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
<kevglass> woot
<kevglass> jinput binaries
<Mazon> :)
<aho> :o
<kevglass> spose I'll have to find time to sort it out now :)
[...]
<aho> thought about throwing some getSimpleX/Y() methods which also throw in pov stuff (makes it rather reliable... so i've heard) :>
<kevglass> post it on the forum
<kevglass> let someone decide
<kevglass> I'll just do whatever the concensus wants
Opinions please :)
Hi, nice work with the joystick support! :D
Though I have some issue:
When I enable polling of events for the joystick controllers my keyboard and mouse stop responding in the application. I have a combined mouse and keyboard device which has category 'device' (neither keybord nor mouse; on Windows) - any ideas what to do?
(One could search for "Mouse" or "Keyboard" in the name, but I would consider that pretty dirty...)
Second thing: I don't like the constantly created event-objects :? (after a while the gc has to collect them and causes lag, no?) Any chance to get rid of them? E.g. doing method calls with current event fields as parameters?
Btw. any plans for rumble support? :)
Try calling Controllers.create() prior to Display.create().
I'm not really sure if thats still necessary with the current version (included in lwjgl 0.98 )... however, it does work there, too.
And those few objects. They are tiny and short-living. They aren't a problem at all (even on the slowest machine here... its a k6-2 300mhz/128mb/voodoo banshee 16mb).
Recreating buffers is slow (re-use em) or creating several thousand objects per frame, but a handfull tiny wrapper thingies dont change a thing ;)
(Always use a profiler prior to optimisation)
It helps, thanks!
Regarding the event objects: whatever you say :wink:
- can that really be measured by a profiler? Which one?
I didnt really took a closer look. I just know that there wasnt a measurable difference between the version without input stuff and the one with input stuff. Therefore I didnt bother to do any real comparision ;)
Either way its like 0-5 tiny objects per frame. You can create way more objects before it gets troublesome.
And profilers... well, you can try the -Xprof and -Xloggc:<file> flags. You can also try the rather new netbeans profiler (http://profiler.netbeans.org/) or one of those eclipse profiler plugins (http://eclipse-plugins.2y.net/eclipse/plugins.jsp?category=Profiling).
When using a Controller, how do I know which of the GetXAxisValue/GetYAxisValue/etc. methods represent something on the controller, and which are inert because the controller doesn't support them? Do I have to use getAxisName to find out which are present?