HID Input Library - give me your wishlist

[Fenris]

Hi all,

Every now and then, people whine about Apple's HID (essentially gamepad/joystick) SDK support. The HID Manager isn't exactly straightforward, and while the HID Utilities are nice, they're just halfway towards being really good.

What I'm planning to do is to write a proper framework for handling gamepads and joysticks (with bindings in C++ and Obj-C) during the coming autumn, and I would love to hear some input on what you want it to do. So, all those things you never dared ask for goes here. ;)

[Zwilnik]

#include "GamepadLib.h"

InitGamepad();

ConfigureGamepad(n);

ButtonArray = GetGamepad(n);

that's all I want to see :)

[Danlab]

#include "GamepadLib.h"

InitGamepad();

ConfigureGamepad(n);

ButtonArray = GetGamepad(n);

that's all I want to see :)


i prefer

InitFrenchGamepad();

ConfigureCheeseGamepad(n);

ButtonArray = GetFroggyGamepad(n);

et voila :lol:


its a good idea, remember to add the forcefeedback too

[Joseph Duchesne]

InitCanadianGamepad();

ConfigureCheeseGamepad(n);

ButtonArray = GetFroggyGamepad(n);

forceSomeFeedBack(n);

And poof! Force feedback.

Or you just use a big heavy bass and hope they have a nice sub-woofer.

[unknown]

Support for multiple mice please!

[Fenris]

So basically, would a data structure that doesn't do much more than metadata (controller name/vendor and type), button state bit array, and normalized vectors for analog sticks be the preferred format?

Considering that HID presents most input elements in a tree structure, which is truly annoying, I'd like to flatten that into just such arrays as Zwilnik proposes. Is there a reason for anyone to keep the hierarchy alive in the framework?

[Danlab]

just make it simple !

return all in c string or int or float
dont want to play with aother stupid tihng that eat time

for exemple you can create some fonction that return the gamepad name
gamepad_givename(gamepadID, &namethingy);
gamepad_howmanygamepadpluged();
gampad_button_1(gamepadID)
gampad_button_2(gamepadID)
gampad_button_3(gamepadID)

i think nobody care about the hierarchy

[Zwilnik]

If I see the word Handle I'll hit someone ;)

Simple is definitely the way. If anyone wants some sort of extra uber complicated functionality they can bolt it on afterwards.

If the aim is to make a straightforward HID framework then the simplest common format is best. Ideally, make it so that 'Gamepad' is a common set of functions for reading an actual gamepad *as well* as keyboard.

As Dan suggested, duplicating the functionality of the array with straightforward button checking functions (button held or button pressed being particularly useful) would do no harm either.

[codemattic]

I was quite fond of Amelio, but it never caught on. It could be used from carbon or cocoa. Worth taking a look at.

It had a seperate app that you could use to make graphical GUIs for your specific devices - so that the interface would have an image of your joypad and show you where the controls were. And when it started up it checked on the web for GUIs that anybody else had already created for your device. If it couldnt find a driver and you didnt want to create one it used a regular pull-down menu for whatever controls it could find.

It also let you calibrate your analog controls.

It used to be hosted here on idevgames.com, but has gone away.

[Nick]

I would rather see this as an OO thing rather than take the form of SDL like you suggested. Something more like this:


//choose your favorite method of creating the object
HIDGamePad *pad = HIDManager::getSingleton().createGamepad();

pad->isButtonDown(n);

float x = pad->getXAxis();


I just believe that format is more appealing.

[unknown]

if a higher level OO structure would suit you better then it would probably make most sense to implement that yourself on top of an easy to use lower level structure.

[Skorche]

I kind of agree with unknown. An easy to use low level structure would be preferable. That way you could do whatever with it.

I'm fairly fond of SDL because it works with pretty much any input device. Being able to use input in a unified way from the keyboard, mouse and gamepads/joysticks is nice. It's event loop is also nice.

My wish-list:
* Joystick axes return floats. [-1, 1]
* State polling. (i.e. get_joystick_axis_value(joynum, axisnum) -> float)
* Support for event loops. get_events() -> a list of events since the last call
* C interface.
* keyboard values map to ASCII when possible. (really handy in SDL)
* Multithreaded support. :p

[aarku]

What to do with out of spec devices? (Like mice that report 256 buttons...)

This has to be a easy to use low level C interface. It's the common denominator.

-Jon

[Zwilnik]

What to do with out of spec devices? (Like mice that report 256 buttons...)

This has to be a easy to use low level C interface. It's the common denominator.

-Jon

Totally. no point in doing a C++ only interface, might as well waste time with the Apple HID library for that.

As far as device spec. decide on a reasonable maximum number of buttons and controls and limit to that. If a controller is reporting more than 4 analog axis, a dpad and 16 buttons, just ignore the extras. That way it makes the interface (for both coder and player) more straightforward. If company x wants you to support their funky 256 button mouse they can write a driver for it :)

Games get designed to the minimum spec for controllers anyway, so there's no point in overcomplicating the API just to support wierd stuff.

[Fenris]

Awesome input (heh!) everyone, keep it coming. I might get this off the ground sooner than planned just because I'm so intrigued! :)

[Zwilnik]

one other request. if the API also solves the issue of getting mouse and keyboard input while in a window or fullscreen in Cocoa it would be great. A one stop game input API :)

[Cochrane]

My additions to the wishlist:

- Hatswitch support similar to joystick axes, i.e. in addition to "joystick x [-1 to 1]" have "joystick hatswitch x [-1 to 1]"

- Some easy way to identify any input element at runtime so I can save them and allow them to be customized

- Support for multiple joysticks/gamepads is nice (but not exactly necessary)

[socksy]

• Ease of use (see first reply)
• Work in C
• Allow users/driver writers to assign names to buttons/axes. I have no idea what Button #14 is on my 15 button Xbox 360 controller, when told to press it on Halo (for instance)

Looking forward to seeing it! Thanks for taking on the job.

[PowerMacX]

My additions for it to be game programmers' best friend:

Compatible with SDL event handling (or if not possible, make it cover keyboard & mouse input transparently)
Option for it to automatically prepare a mean espresso every ~4 hours of coding...

[Skorche]

My additions for it to be game programmers' best friend:

Compatible with SDL event handling (or if not possible, make it cover keyboard & mouse input transparently)


I disagree with that. If you want SDL events, why not just use SDL? Besides, doing that would add pretty severe limitations, and be pretty hard for poor Fenris to achieve.

[OneSadCookie]

SDL has its own joystick handling; is it not adequate for your purposes?

[lightbringer]

SDL has its own joystick handling; is it not adequate for your purposes?

Not for mine. Each time SDL launches it scans the USB chain looking for devices (that adds about two seconds onto the launch time of the application - two seconds is an especially long time when you run the app lots of times to work on it).

I want a solution like El Ballo (http://www.ambrosiasw.com/games/elballo/) had (it's worth picking up a copy for yourself) where it caches the data and unless the user selects another gamepad, tries to use that gamepad (correct me if I'm wrong Ivan - I sometimes have a bad memory when it comes to specific details of stuff I've explored, I really should write some of this down). I also had troubles getting joystick axises to return accurate values (I even went out and bought another one, thinking the hardware was defective)

If of course if this could be spawned off into another thread, that would probably be ideal for the two second delay (although I don't like how it just gobbles CPU cycles in the process, IIRC).

[PowerMacX]

I disagree with that. If you want SDL events, why not just use SDL? Besides, doing that would add pretty severe limitations, and be pretty hard for poor Fenris to achieve.

So, if I'm reading this correctly, there is still hope for my second suggestion? :p

SDL has its own joystick handling; is it not adequate for your purposes?

Last time I tried it, it just plain didn't work (didn't detect anything nor gave any errors), but that was a while ago. I'll do some testing with the last version once I can borrow some controllers to try against.

[OneSadCookie]

I've used joysticks with neverball and spacetripper, and they seemed to work well there. Both have their own calibration code, of course. The startup performance penalty doesn't sound like fun, though.

[Skorche]

Derek: I have noticed that SDL seems to use an inordinate amount of CPU to process events. (In some cases, more than the Ruby code it calls to use them) I've never noticed a startup delay though. Does it depend on the gamepad you are using?

[lightbringer]

Derek: I have noticed that SDL seems to use an inordinate amount of CPU to process events. (In some cases, more than the Ruby code it calls to use them) I've never noticed a startup delay though. Does it depend on the gamepad you are using?

Although I don't want to get too off topic, here's what I'm talking about:


if(Settings.USE_JOYSTICK) // or gamepad
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_JOYSTICK);
else
SDL_Init(SDL_INIT_VIDEO);


It's simply calling 'SDL_INIT_JOYSTICK' that causes SDL to search the chain and create a delay.

[Zwilnik]

would adding SDL event compatibility force linking to the SDL library? If so forget it, not all of us use SDL or want to use it.

If the HID usability library gives you gamepad/mouse/key input anyway I can't see much point of SDL event compatibility to do the same input.

[PowerMacX]

If the HID usability library gives you gamepad/mouse/key input anyway I can't see much point of SDL event compatibility to do the same input.

That's the thing, either joystick support in a way that still allows SDL to manage other events (window/keyboard/mouse) or support for mouse & keyboard so SDL event support is not necessary.

Anyway, as long as it has a C interface, it shouldn't be a problem to integrate at a later point (a fork?) if it turns out to work better than SDL's joystick support.

[unknown]

Here is some code that may prove to be a useful starting point.
http://www.idevgames.com/forum/showthread.php?t=13336