JInput - suggestions for improvements

Engines, Libraries and Tools JInput
#1

Here is my wishlist for improvements of JInput:

a) throw away the concept of Controller instances having child Controllers:
I see no use in this - it is difficult to program a plugin supporting subcontrollers and makes it more difficult to use such a plugin. Furthermore there is no statement which set of Axis instances has to be grouped together as a subcontroller.

b) throw away the concept of portnumbers:
its of no use for the end user (player of a game) and nearly no platform/input device has meaningful data for it (eg PS2 has no numbered ports and USB is hierarchical, not numbered)

c) allow plugins to throw an exception out of their constructor which can be retrieved via a special listener registered at DefaultControllerEnvironment when the Controller array is requested
this makes plugin developement and usage (configuration probs) easier

d) make mice and keyboards ordinary input devices (no need to subclass Mouse/Keyboard):
this simplifies plugin development

e) revise the usage of Axis.Identifier:
do a little requirements engineering - what are the benefits of UUIDs for input devices and which problems do they really solve

f) introduce Axis.Type like Controller.Type and Controller.PortType:
this allows an application to search programmatically for certain kinds of hardware features

g) clean up core API:
eg. Axis.Identifier.KEYBOARD has ‘buttons’ as name

h) general:

  • attract more people
  • hold open discussions (involve users, not only API developers)
  • urge people to implement plugins for other OSes (where Java 1.4 is available)

ok, thats a lot. Lets have a nice discussion on this :slight_smile:

(would it be better to split this in several threads?)

#2

I disagree with ‘a’ - I think the sub-controllers idea could be great for grouping things like hat switches and directional buttons. Better than having them 4 separate buttons.

I’m not sure I agree with ‘d’ either. What is so bad about sub-classing?

#3

You missed:

x) revise the complex plugin system altogether since its constantly causing problems.

y) write a tutorial and some documentation

z) Actually make it work consistantly on the 3 “standard” platforms properly.

In addition

  1. Support an event based input system aswell as the polling stuff. This is useful for configuration of controls. This may already be present and I just missed it?

  2. Support configuration GUIs from the core package. You might aswell, everyone is going to have to write one anyway.

In response to the points above:

a) This is probably just in your use cases it doesn’t make sense. It does in a quite a view.

c) Sure, but lets not expose it as an exception if its going through a listener interface. Should probably be able to retrieve a list of PluginConfigurationError objects from the DefaultControllerEnvironment. Getting people to put useful text in here might be a challenge aswell.

d) Don’t see why this causes anyone a problem. If you don’t extend Mouse or Keyboard you can still implement mice and keyboards as Controllers direct.

The rest is pretty general, but I agree with most of it. I’ve used JInput in a few games now and each time I’m writing a cleaner and cleaner wrapper.

With the lack of interest/time spent on JInput the easiest way to get something done might be change your own version then send it back to the maintainers as diffs. Hopefully, they’ll be some changes then. :slight_smile:

Good ideas!

Kev

#4

Hi
Just my thoughts, I seem to be the only ‘active’ jinput dev now, I guess Jeff is very busy, but it’s not my API, so I can’t force or veto anything.

a) They could be usefull, like swpalmer said.

b) no thoughts, it does seem to be redundant, but I’m sure there was a reason for it.

c) eugh, like kev said, maybe a collection of errors though.

d) they are already, you only extend those objects as they provide functionality that is common. There is no real requirement to use them though.

e) I agree that the story on this is a little vague at the moment, I’m trying to get some info from Jeff on this.

f) sounds interesting.

h) More people writting plugins for other platforms would be nice, the talks generally at the moment are between you and me :), It’s not that anything is being talk about behind your back, it just doesn’t seem to be being talked about :(.

x) The plugins system is a bit fidly, but it seems to be better now with the extra options, the thing that is causing the most problem is that the docs on these are non existant (apart from my posts which still arn’t sticky)

y) Jeff started something I believe, no news on this though

z) Or work at all ;), I’m not sure of the status of the OSx plugin now, last I heard the nightlies where knackered for it too. Linux should be working on the most part, I have some updates to do though, and rumbler support is missing there. Part of the problem is that the 3 platforms don’t behave the same, so trying to write something that does, that doesn’t require drivers for lots of different hardware, is a right p.i.t.a.

  1. yup, it’s missing

  2. If you have one, fancy posting it? :slight_smile:

If you have something that you want commiting, that isn’t a change to the API, then fire away, changes to the API itself will need to be checked over with Jeff

HTH

Endolf

#5

Hey Endolf and Scott, can you pool your collective Mac-HID wisdom and get the LWJGL input stuff working for us :stuck_out_tongue: ?

Cas :slight_smile:

#6

The next two blank lines will sum up my total wisdom on mac input

:slight_smile:

Thanks

Endolf

#7

Thanks for the replies.

a) All of you see some usefulness in this. please enlighten me with details. My opinion is that topological information is of no use for gamers. Maybe it is a bit related to f (Axis.Type suggestion) which will provide IMHO enough information.

c)
I agree I was a bit to specific at this point. I just felt the need for passing around exceptions.

d)
Are Mouse and Keyboard really helper classes? Would (API) user never expect that this holds (controller.getType() == Controller.Type.KEYBOARD => controller instanceof Keyboard) ?

x)
What ‘complex plugin’ system do you mean? JUtils? Then you are probably right but I did not dare to bring up this topic again :smiley:

y)
This is one really good suggestion but writing extensive docs before the API is partially stable is not a good idea. Anyways I got to know JInput from all sides (thats my reason for nagging :slight_smile: ) and would help writing some comprehensive docs/tuts.

z)
Mmh yes that would be fantastic. I can only help out on the Linux side :frowning:

Event based plugin is a hot topic that needs further investigation.

Don’t know what you want to configurate at core level. IMHO configuration is strongly application specific … and err not everybody has access to AWT frames …

h)

[quote]… but it’s not my API …
[/quote]
Thats the reason for h) who’s API is it? It is not that good if the project lead is away for some uncertain time and meanwhile development halts and nobody dares to advance. This board has other capable members too: eg. Herkules has written JXInput and may be willing to join.
I find this a rather difficult topic because I do not want to sound heretic or start unfriendly discussion but this opensource project is not so ‘open’ as it can be …

#8

[quote]Thanks for the replies.

a) All of you see some usefulness in this. please enlighten me with details. My opinion is that topological information is of no use for gamers. Maybe it is a bit related to f (Axis.Type suggestion) which will provide IMHO enough information.
[/quote]
It is useful to plugin implementers and game programers. It provides structure to complex controllers that make things easier to manage. My mention of 4 buttons that are actually a direction pad is an example. Used properly I see sub-controller grouping as a good thing.

The BIG problem is that controllers are implemented inconsistently. Some show a direction pad as 4 buttons, some use 8 buttons, some as a single axis with 9 states… bloody morons screwed it up for everyone :P.

When I was working on gamepad support for the Mac plugin this was what stopped me… I would need massive tables and a complex system to “normalize” controllers that were otherwise identical to the end user. It just made me mad and I gave up.

#9

Yeah that is probably one of the biggest show stopper for this. We cannot guarantee conformance of every device for this. On Linux HID is not a big problem because the kernel people have already written the hard stuff (that would be a good source maybe). But there are other problems like inconsistent usage of constants describing the type of a feature. I have a gamepad with 2 analog sticks on it (Thrustmaster Dual Analog 3). Linux says one of them consists of
ABS_RZ (actually the X axis) and ABS_THROTTLE (actually the Y axis).

I think it is impossible to group axes (and other stuff) if there is no consistent support from drivers.

Btw: have you ever met phantom features? That means the driver reports stuff that is not available as hardware … I have many of them here (Linux) and only some of them can be identified as phantoms.

#10

[quote]I think it is impossible to group axes (and other stuff) if there is no consistent support from drivers.
[/quote]
The solution is to make a database of devices that can be shared between plugins? Apple uses an XML database of known controllers to help with this for their HID stuff. Mapping HID " usages" to meaningful button names. Mayeb we need something similar? Shame really, since the USB HID spec has most of this stuff worked out, but the device manufacturers didn’t follow it so where HID has a specific usage for a hat switch you get a device with 4 generic buttons. Major bummer for us programmers that want to work with these things.

#11

I wonder what kind of key can be used to address a device in that database. That key should be platform independent, too … Hm sounds tricky.

#12

Well for USB devices it is easy enough - they have vendor/device ids already.
For old-style gameport controllers ro something that goes on a serial port etc… that may be more difficult.

#13

Well, here’s a counter-example: I’m not using JInput because of the lack of docs.

I’ve always been taught that - like testing - you update your documentation as you go, and that people who wait until the app is finished before writing the docs suffer many times over. Personal experience bears this out.

I wonder how many others are put off by this? My main reason for not using LWJGL for more than a year was simply that it had no documentation, and I’m not going to waste months of my life reverse engineering someone else’s code just to try and use it. For many people, no docs == no library/application at all.

#14

A much better reason for not using LWJGL is that it’s still in alpha and we keep buggering the API about massively to get it just right :wink:

Cas :slight_smile:

#15

@blah³:
ever looked at JInput’s doc at all? It is not completely empty. Spending month for understanding is simply exaggerated. JInput is a input library not SAP R3.

here are all the import I needed to write an input abstraction layer which is based on JInput:

import net.java.games.input.Axis;
import net.java.games.input.Controller;
import net.java.games.input.ControllerEnvironment;

Huh complex …

OK back to topic: JInputs simplicity does not justify its lack of documentation but like cas mentioned with LWJGL I consider JInput to be in alpha state as well: A potential for changes in the public API is present.

Btw: It is however nice to see that people start noticing this project at all :slight_smile:

#16

hey, Im rather new to jinput, but it seems to me that this is way overkill for a lot of stuff. how hard would it be to make a jinput light? something designed only to use ONE keyboard (as great as it is to support multiples, not many people have these ;-)) One mouse (again the same applies) and one game input device. Keyboard polling would just ask the keyboard if key such and such is down, mouse poling would just get the x or y direction of the mouse. treat it as a mouse, not a whole bunch of different stuff. I think its safe to say that allmost ALL mice out there are 2 button (some with scroll, soo add that too, and i know about macs, i have one) so just support that in the light version… If people want to use something more advanced, they can delve into your allready made EXTREMELY ritch library of handleing ANYTHING. Lastly game controllers… 99 percent of them out there are going to be usb. so why not make it so… you discover the controller by pluggin it in when the program promps. the program finds the newly added device, and then asks the user to configure it. up is promped for, left, right down, all in turn, then buttons one through whatever. This is of course IF the user even wants to use, or has a controller (certainly not a given amongst the computers out there) For a good chunk of people that will be using this, simple is the only option. if people use jogl, the come to jinput for their input. its the only real choice, so why not give them a simple, and less powerfull solution? it also would probably take less space for download too. Just some thoughts, keep up the good work on the library, its amazing in what it can do :smiley: I would just like a light version.

#17

[quote]hey, Im rather new to jinput, but it seems to me that this is way overkill for a lot of stuff. how hard would it be to make a jinput light? something designed only to use ONE keyboard (as great as it is to support multiples, not many people have these ;-)) One mouse (again the same applies) and one game input device. Keyboard polling would just ask the keyboard if key such and such is down, mouse poling would just get the x or y direction of the mouse. treat it as a mouse, not a whole bunch of different stuff.
[/quote]
How is this significantly easier than the current JInput, assuming that all the bugs and bits of “we could have designed this interface better” were sorted out? (which seem to be only hampered by people’s free time, and I’m assuming would not be changed any quicker by doing a light version?)

But this is clearly not even close to being true; if you’d said nearly all were ONE button I suspect you’d have been slightly closer to the truth :P. I haven’t seen a 2 button mouse in well over 3 years, unless you count laptops, or the broken one that was sitting in our “old PC equipment to give/throw away” box. Almost every windows user I see these days has a 5-button or more mouse, and now that the dual-mousewheel versions only cost $20 they’re popping up a lot too (in the UK, small hardware shops often run out of one-wheel mice and/or have deals on the 2-wheelers, so you see lots of “normal” users who have one just because it was easy to buy, nothing to do with actually WANTING two wheels ;)).

AFAICS part of the raison-d’etre of JInput is to force an “intelligent” approach to input handling on games developers - one which is actually easier to code, easier to maintain, and methodical - and for free it actually gives players near limitless options on controllers (assuming the game itself has rudimentary GUI to re-assign controls etc ;)).

I’m just waiting for good, simple, readable docs and a quick-start guide AND a stable interface to the API to come along…

What would be really nice is an API on top (or, even better, an optional add-on for JInput) that automates almost everything, even to the extent of doing 90% of the work of having in-game customizable controls (i.e. does everything bar actually display the in-game GUI - although it would be great if it did that, with a simple-yet-effective skinnable Swing GUI, for testing and RAD of games; being able to re-use someone else’s GUI for this whilst doing alphas and betas - no matter how ugly it looks - would be well worth it to those of us trying to develop games in narrow time constraints). This kind of thing I doubt you’d ever want actually inside JInput.

(If any of that is already in JInput then all I can say is … document it a bit more! How the heck do I know that’s in there? I don’t have time to go around reading javadocs (which are not, in case anyone here needs disabusing of this notion, a replacement for developer-documentation))

#18

[quote]@blah³:
ever looked at JInput’s doc at all? It is not completely empty.
[/quote]
So, I braved the four-clicks and extreme slowness of java.net once again ;D to try this out.

And yes, there is still no documentation for JInput. At least, none I can view. I even tried downloading the zip file of the jdocs, and gambled that someone had used javadoc to create dev docs (hint: if there aren’t package.html files included then the answer is almost certainly “no”), but quel surprise they had not.

Sorry if I wasn’t clear - I’m only able to use jinput in my free time. The free-time approach means I can only invest small chunks of energy and concentration (perhaps half an hour at a time at most). Without developer documentation this process of learning is artificially slowed down by the extra effort that is demanded of the reader to read someone else’s API documentation and try to infer the developer documentation that should have been written but hasn’t.

The main problem is that you forget where you’d got to by the time you get back to trying again. On top of the difficulties inherent in experimenting with an API like this that deals with hardware, where your evil hw manufacturer may have done arbitrarily many bad things in writing their drivers :).

In all fairness, I reckon if I was able to spend half an hour a day every day for a week I’d probably know what was going on. If I had really “normal” hardware it might take less; if I had lots of linux hardware, it could take a month easily because lots of hw drivers on linux are crap and end up getting you into a chain where you have to upgrade your kernel to recompile a custom version of a new release of a patch to the old version (latest has a fatal bug) of a special branch of the driver 8). Not JInput’s fault, but if I know that could happen, and on top of that JInput doesn’t have dev documentation to start me off, it’s hard to find the courage to try Jinput frequently as opposed to infrequently…

#19

…light version? sounds like LWJGL input to me…

Cas :slight_smile:

#20

JInput really isn’t rocket science. Even without the docs it literally took me a few hours (read 3) to get it up and running with Martian Madness. To say it doesn’t need docs is wrong (but I don’t think anyone has), to say its not possible to use without docs is also wrong.

However, saying all that I still think it could have been a bit prettier. The first think I did when using it was to write a wrapping layer and it sounds like TheBo did the same thing. Maybe thats because we like wrapping stuff up or maybe JInput’s interface is just too poor to work with directly.

Seems to me that the Use Cases for JInput were slightly off. When using it in games getting all the details of the controller is very nice but when it actually comes down to it you have to configure against controllers and then check the configured inputs and thats it.

So for instance, you might have four controls in your game. You need to be able to say for each “I need a digital control for this one” or “I need an analogue control for this one”. Next you need to be able to configure your controls… ask the API to check all controllers for either an analogue or digital control change. It returns you the next control to be pressed.

Finally during the game you want to be able to check the state of a configured control. While it nice to have an all encompassing input access layer, for games used it seems to be a bit overkill.

Kev