Controllers

[Matzon]

Definitely the Kevglass way. We certainly don't want to pass an index around to all methods.

Aye, but now you're passing a Controller around. Threre is also option 3, setting the active controller before playing with it - kinda like pbuffers. Then we wouldn't have to pass anything around...

As for controllers being able to handle all cases, we have a slight problem. There are literrally thousands of different devices out there. And I think we should just make our api support common controllers (whatever that may be) and not go the axis route. The JInput way of doing things, is really messy. Flexible, but messy. And the end result is that you have a developer that doesn't even know how to use the controller api!

What we have right now might not support *all* devices equally well - but it sure as hell is simple to use.

That said, the current controller api hasn't gotten the testing it deserves, so there might still be issues in it wrt. axis/pov/rot

[kevglass]

Fair point, so you reakon it should be done something like:

class Controllers {
 static int getControllerCount();

 static Controller getController(int i);
}

class Controller {
 int getButtonCount();

 boolean getButtonState(int i);

 int getAxisCount();

 double getAxisState(int i);
}

I'd be worried about not identifiing Axis specifically. While most of the time the game needs to get the user to configure their controls (i.e. move the stick in the direction you want the banking of the plane to be) assuming that devices are consistant on reporting their axis it would be possible to do some auto configuration.

Probably the answer is if the device reports the same axis twice then its a "Just pick one". However, this would be pretty odd behavior from any controller.

I still think passing a Controller is preferable, you hold the reference to the controller your using and call methods on that. If you have an int you have to pass it in to every call. Setting the active controller might be cool, but if you're supporting multiple controllers this could get irritating switching all the time (thread safety, complexity of the underlying code).

I'm still of the opinion that the currently Controller interface is fine, it just needs to be non-static and have a manager type class that dolls out Controllers on an indexed basis.

Kev

[elias]

I'm thinking something along the lines of a simple Controller with the ability to explore all it's axes, buttons and whatever. Kind of like extensions to the Core GL (which by your argument should be removed - you don't need anything else than GL11 to make a game)

- elias

[kevglass]

While I see your point I think theres a considerable difference between missing extensions and missing repeated axis. However, how about a combined interface then...

Controller as it is now, i.e. with getPov() and getRx() with the addition of:

int getAxisCount();
int getAxisState(int i);
String/int? getAxisName/Type(int i);

This way for general purpose its really easy and for any extended controls the functionality is still there.

Kev

[elias]

Well, for the axis state I like floats better (range 0..1?). And we need some kind of event queue functionality like the mouse and keyboard.

- elias

[elias]

I don't think there's a way around an Axis object with type, state and queue.

- elias

[kevglass]

Axis object internally for sure, its whether they get exposed to the outside world or not? Does an axis without a controller really make sense?

Float range might be better -1 .. 1 since axis normally centre on 0.

Kev

[elias]

Axis instances are only visible as an interface returned from Controller.getAxes().

- elias

[elias]

Regardless of the public LWJGL API, wouldn't it be a good idea to develop a common HID interface to all platforms to use as basis? HID is supported on win32, linux and mac and using the same underlying terminologi and interface would simplify the development a lot.

- elias

[cfmdobbie]

Would that fix the DirectX NT issues as well?

[kevglass]

Reading about a bit, it seems like HID is the right way to go. Although there arn't many examples of using it on Windows. I suspect it'd take a bit of playing around with..

I'll go and have a play...

Kev

[elias]

Great. It could actually be a separate "jHID" implementation that LWJGL Controller then builds upon.

- elias

[kevglass]

Just been looking at jUSB and libhid. Neither seem to be properly complete or available

Kev

[kevglass]

libhid is absolutely naffed. libusb is available (ish) but isn't really complete.

jusb is available for both windows and linux (although limited) but requires you to come along with a new device driver which doesn't seem all that great to me.

So the options appear to be:

a) Write a wrapper for the different HID functionality on each platform (even tho its not exposed fully on windows).
b) Write a wrapper around the exposed input APIs on each platform, basically whats been done already but more.
c) Use the JInput plugins but get rid of that infernal plugin system and wrap the API is something thats easier to use.

Any others...?

Kev

[elias]

a) or c) is the way to go I think. I wouldn't worry about windows lacking some HID functionality because DirectInput itself uses HID for HID enabled devices.

- elias