next »

[melos]

I'm going to go and dive into google/documentation in a bit, but I figured someone might be familiar with this. I can't find a native AIR extension that supports the dpad (I think brett chalupa's only does joystick?), in any case,

is there some sort of standard protocol for external gamepads, and do you have any recommended libraries for interfacing with the gamepad blah blah blah? .

I haven't really worked with C++ before (I've done a bit of C) but I figured it wouldn't be too hard to do something like this. Maybe I am totally wrong.

Anyways if anyone could point me in the right direction before I go get lost I would appreciate it!

[ThemsAllTook]

I wrote one. Feel free to use it as-is or as an example: http://sacredsoftware.net/svn/misc/StemLibProjects/gamepad/trunk/source/gamepad/

Getting raw input from a gamepad isn't too hard, though you'll have to use a different API on each platform you support. My library provides a thin abstraction layer, which allows you to use the same API on the 3 big desktop platforms, but doesn't do any additional translation or mapping or anything. The tricky thing about gamepads is that they're wildly inconsistent. A typical gamepad will most likely have different button mappings across platforms, report phantom buttons that don't actually exist, map its axes in unintuitive/backward ways, and give you no hint whatsoever about its physical layout. Dealing with these things is tricky, but not impossible. If you have the player set up their gamepad by pressing each button you want to map to an action rather than trying to autoconfigure it, it can work. If you want to provide sensible defaults, you'll need either an enormous database of controller layouts, or to restrict your support to only a few devices.

Totally worth it to be able to play your games with a gamepad, though!

[melos]

Thanks dude! Yeah I'm going to have them press each input one by one, since there are only three then the dpad.

[Dataflashsabot]

I wrote one. Feel free to use it as-is or as an example: http://sacredsoftware.net/svn/misc/StemLibProjects/gamepad/trunk/source/gamepad/

Getting raw input from a gamepad isn't too hard, though you'll have to use a different API on each platform you support. My library provides a thin abstraction layer, which allows you to use the same API on the 3 big desktop platforms, but doesn't do any additional translation or mapping or anything. The tricky thing about gamepads is that they're wildly inconsistent. A typical gamepad will most likely have different button mappings across platforms, report phantom buttons that don't actually exist, map its axes in unintuitive/backward ways, and give you no hint whatsoever about its physical layout. Dealing with these things is tricky, but not impossible. If you have the player set up their gamepad by pressing each button you want to map to an action rather than trying to autoconfigure it, it can work. If you want to provide sensible defaults, you'll need either an enormous database of controller layouts, or to restrict your support to only a few devices.

Totally worth it to be able to play your games with a gamepad, though!

Doesn't look like yours fully supports the very popular 360 controller, unfortunately. I was making a 360-only library (with guide button detection, even!) which I can finish and release if there's interest, but XInput is quite easy to use anyway.

edit on preview: But you don't need XInput if you don't need to support the triggers or vibration.

[Klaim]

I use OOIS as library abstracting all inputs, not sure how it works for gamepads but never heard complains about it.

The only thing is that the forum is a bit hidden now that there is no obvious way to find it: http://www.wreckedgames.com/forum/

Also, it is updated very slowly so if something is missing or buggy, don't assume it will get fix quickly; I didn't have any major problem with it for now.

Documentation is missing because the wiki is lost, but the code is pretty straightforward to follow, just look at the interface and example.

Wow I just discovered that it have a github now: https://github.com/wgois/Object-oriented-Input-System--OIS-

So not sure it's the best for what you need, but it's the closest thing I know.

There is also a library by someone else to abstract "actions" which are triggered by composition of inputs, it's useful to help building configurable inputs. I can't find where I found it but it was in the Ogre forum I think. Anyway I find it not really well designed so I decided to go with mine (and it's a bit more specific design anyway).

Another way to do it would be to look into one of the sub libraries (which are independant) of SFML.

[melos]

I wrote one. Feel free to use it as-is or as an example: http://sacredsoftware.net/svn/misc/StemLibProjects/gamepad/trunk/source/gamepad/

Getting raw input from a gamepad isn't too hard, though you'll have to use a different API on each platform you support. My library provides a thin abstraction layer, which allows you to use the same API on the 3 big desktop platforms, but doesn't do any additional translation or mapping or anything. The tricky thing about gamepads is that they're wildly inconsistent. A typical gamepad will most likely have different button mappings across platforms, report phantom buttons that don't actually exist, map its axes in unintuitive/backward ways, and give you no hint whatsoever about its physical layout. Dealing with these things is tricky, but not impossible. If you have the player set up their gamepad by pressing each button you want to map to an action rather than trying to autoconfigure it, it can work. If you want to provide sensible defaults, you'll need either an enormous database of controller layouts, or to restrict your support to only a few devices.

Totally worth it to be able to play your games with a gamepad, though!

Doesn't look like yours fully supports the very popular 360 controller, unfortunately. I was making a 360-only library (with guide button detection, even!) which I can finish and release if there's interest, but XInput is quite easy to use anyway.

edit on preview: But you don't need XInput if you don't need to support the triggers or vibration.

All I need is the down/up state of directional pad and three buttons, I should be ok?

[ThemsAllTook]

Doesn't look like yours fully supports the very popular 360 controller, unfortunately. I was making a 360-only library (with guide button detection, even!) which I can finish and release if there's interest, but XInput is quite easy to use anyway.

edit on preview: But you don't need XInput if you don't need to support the triggers or vibration.

All I need is the down/up state of directional pad and three buttons, I should be ok?

Yeah. All of the other buttons work (and I think the guide button depends on your driver; I know it works on the Mac with the tattiebogle driver and maybe on Linux, but on Windows it won't register). As far as I know the triggers work too. Vibration is something I should really get around to adding, though...

[ham and brie]

As far as I know the triggers work too.

They might not work together. XInput gives separate axes, but with joyGetPosEx they are combined as one axis, so both held is the same as neither held, even though it's common for games to want both to work (e.g. aim mode and fire).

[melos]

Ah, well that will be an edge case not covered...but I think there are other buttons near those triggers, right? So someone missing a left thumb would probably be fine?  at least for anodnye.

Right, I'll try to get this working today, probably with ThemsAllTook's library first since it is smaller and I'm not really familiar with getting C++ stuff to work. But that ohter one does sound like a nice option.

[ThemsAllTook]

They might not work together. XInput gives separate axes, but with joyGetPosEx they are combined as one axis, so both held is the same as neither held, even though it's common for games to want both to work (e.g. aim mode and fire).

Drat, I just tried it and you're right. Single axis for both triggers. Guess I'll need to look into XInput after all...

[Average Software]

They might not work together. XInput gives separate axes, but with joyGetPosEx they are combined as one axis, so both held is the same as neither held, even though it's common for games to want both to work (e.g. aim mode and fire).

Drat, I just tried it and you're right. Single axis for both triggers. Guess I'll need to look into XInput after all...

I'm pretty sure you get both axes independently with the raw input API, but I would have to confirm that.

[melos]

am I doing something wrong with the event dispatcher? I added printfs to the gamepad.c stuff and it detects when I move sticks/buttons but none of the event handlers are getting called .

here is my main.cpp

http://pastebin.com/agT2LE62

haven't really looked into it much since i need to run atm but i will later

---

I was fixing pointer cast errors with your code you gave until I just turned on fpermissive to skip ahead. Do you think I could have broken something in that process? I don't think I made any bad casts but if it's not obvious I could just try with those files fresh again

[ThemsAllTook]

Ahh right, you're doing this in C++...hmm, that complicates things a bit. I do use a fair bit of automatic void * typecasting, which is legal in C but not C++. At the very least, you'll probably need to wrap your #include statement for Gamepad.h in an extern "C" {...} block, and possibly your event callbacks too.

This gives me some good insight into what it's like to use my library in C++. Looks like I have some work to do to make it more friendly!

[melos]

ah, okay. i will try this out soon and let you know how it goes.

[melos]

adding the extern "C"s didn't seem to do anything, but since it is reading the controller correctly i think i'll just have the c++ code poop out some array of button states that updates each frame and that will be sent to my AS3 code. so we're good!

-sean

[MadWatch]

I use OOIS as library abstracting all inputs, not sure how it works for gamepads but never heard complains about it.

OIS is great but I had quiet a lot of troubles with it. There are two things anyone intending to use it should know.

First, you must turn on the XINPUT option into OISConfig.h if you want proper Xbox 360 pad support on Windows (it works like a charm when this option is on, but it has problems with the triggers when it isn't).

Second, multi platform keyboard support kinda sucks. Keyboard behavior is different on Windows and Linux (don't know about Mac yet since I don't have a Mac yet). On Windows OIS will give you keymap independent key code, that is if you press A on an azerty keyboard OIS will send you KC_Q. But on Linux it will give you keymap dependent codes so pressing A on any kind of keyboard will always send you KC_A.

But for some games you need both keymap dependent and independent codes. The later is great for directions keys (so that your qwerty WASD automatically becomes ZQSD on azerty). The former is great for commands key (ie press Ctrl-Z to undo whatever you just did in the level editor).

I also noticed some special keys are just ignored. I have a bépo keyboard (a French ergonomic layout), meaning I have an É key where you Z key is (assuming you have a qwerty). But OIS doesn't recognize it at all (it doesn't sent any event when it's pressed) which is troublesome.

I've been working on a patch to fix all these problems. But I must test it on Mac too before I can submit it on the OIS forum.

[Schrompf]

I, too, was using OIS, but I pretty much rewrote all of the windows input handling. Moved all keyboard and mouse handling to RawInput to be able to handle multiple mice/keyboards for multiplayer input. Included the XInput option and then extended all input handling to also fire a digital event when an analogue axis passes a certain threshold, and vice versa. And finally I added hotswapping because RawInput reports a lot of ghost devices that really botch your input handling in case they accidentally come up at index 0.

I once intended to clean it up and release it under some sensible OpenSource licence, but I never came around to actually do it. Maybe when Splatter is finally done.

[Klaim]

MadWatch> Interesting to know that the behaviour is fixed on Linux. I thought it was a general problem to not have the real keys (because it seem it's the same problem with almost all games - I use both Azerty and Qwerty)

I'll have to check if it hasn't been fixed already.


It's too bad we still have to do ourself platform-dependent code to get not-so-raw correct inputs :/

[MadWatch]

I'll have to check if it hasn't been fixed already.

To my knowledge it hasn't been fixed in OIS yet.
I've seen a patch proposal on the forum to fix the Linux behavior but it hasn't been integrated to the git repo. And from what I've seen of it it only fix half of the problem (because only half of keycodes values are standard amongst Windows and Linux).

[Klaim]

Wait, there is also a way to convert any key pressed to it's textual (UTF8 if I remember correctly) value (as a string). Is it too slow for action inputs too? Or does it have the same problem of not providing the localized value on Windows? I remember it was working well few years ago for typing text...