next »

[randomshade]

We already support using keyboard/mouse to use the menus/remap so it's not a huge deal - just kind of unfortunate. I personally prefer to have the utility embedded in the game, but I can definitely see reasons why an external program may be preferred.

I was going to wait until I could get more concrete data before I posted this info here, but I'm not sure when that will be (if ever.) Anyway, I had issues with the Mac version of the gamepad library - not on my Mac - and thus the reason for little data. After sending out the first version of the game with the gamepad support, I received around 20 reports from Mac users (not sure how many total Mac users tested that version of the game, but total number of players was around 2000) of the build crashing in various ways. Most common was crashing when the game was running and a gamepad was connected or disconnected, but also crashes on boot with a gamepad connected already and crashes on application close. Let me state I am not 100% certain the gamepad library is the issue - it could have been bad code on my end. The logs I was getting back from people were not very useful unfortunately, and I could never pinpoint the issue.

I ended up rolling my own version and that seemed to resolve the issues, so I suspect there is something going on in the gamepad library that is not kosher. On OSX, I ended up using Apple's HIDHelper as an FYI, but I definitely looked at gamepad's source for reference and troubleshooting help. Also, I was leaning towards rolling my own version anyway, since my already existing gamepad API for consoles didn't mesh very well with this one and I was wrapping/hacking stuff like crazy.

One of the major downsides to this, was that my implementation doesn't line up with yours in terms of what buttons/axes are registered as what. i.e. TestHarness doesn't report values that work with my implementation and vice versa. Otherwise I would have already shared our mappings thus far. Since I've already gone ahead and rambled this much, here's the link for the curious. The "Controller Ref" tab is the generic mapping. The "Mapping CSV" tab is what we use in-game for default schemes on known controllers (and the trusty keyboard!) You'll notice that to achieve what we needed, we had to support an "Axis as a button" which is sorta weird but works fine in practice.

[1kW]

Oh my ...

This looks like they're trying to record vibrations from in-room speech and convert them to human readable text

[dynamite-ready]

Oh my ...

This looks like they're trying to record vibrations from in-room speech and convert them to human readable text

No... That's not it.

Themsalltook's somehow got a hold of the special edition Ozzie Osborne Dualshock 4. 

[look4awhile]

I'm trying to use this library in my application. Under OSX everything is fine. I had to modify few lines to get it to build under MSVC 2013 64 bit target (_snprintf instead of snprintf), but otherwise it builds fine. However it consistently crashes in joyGetPosEx. When no joysticks are plugged in it crashes under Gamepad_detectDevices. If I plug in my joystick in USB port it crashes under Gamepad_processEvents. Please suggest.

[ThemsAllTook]

I'm working hard to get a DirectInput/XInput conversion of the library out sometime this weekend, which will also support MSVC. Hopefully that'll solve a bunch of things... Just sit tight for a bit!

[look4awhile]

Let me know if you need help testing and all that. I can be guinea pig alright 

[dynamite-ready]

I'm trying to use this library in my application. Under OSX everything is fine. I had to modify few lines to get it to build under MSVC 2013 64 bit target (_snprintf instead of snprintf), but otherwise it builds fine. However it consistently crashes in joyGetPosEx. When no joysticks are plugged in it crashes under Gamepad_detectDevices. If I plug in my joystick in USB port it crashes under Gamepad_processEvents. Please suggest.

Hmm... On OSX you say? Are you using callbacks, or just using the methods to retrieve the joypad state? There's definitely a bug there in my case. A and which version of OSX?

[look4awhile]

Hmm... On OSX you say? Are you using callbacks, or just using the methods to retrieve the joypad state? There's definitely a bug there in my case. A and which version of OSX?

10.9.2 and I'm not using callbacks.

[ThemsAllTook]

Phew... So, it took all day, but I think I finally have DirectInput and XInput doing what I want. Anyone on Windows care to try this out and let me know if it works for you? It'd be particularly helpful if you have more than one Xbox controller handy; I wasn't able to test multiple XInput devices at once myself: http://ludobloom.com/temp/gamepad_testharness_dinput_test.zip <- Has major memory bug, don't use; see post on next page for fixed version

Haven't gotten to MSVC support or solving the OS X problems just yet, but they're next on the list if everything is OK here...

[angelk]

Hey Alex, I wanted to let you know I've been using this gamepad library for about a year now and I really appreciate all the work! During a Ludum Dare a while ago I added support for it to my game engine, which uses the creative coding library Cinder (libcinder.org). I just updated to the 1.3.0 release of the code and created a plugin for Cinder (known as a block) and put it on Github. Hopefully this is useful for anyone else who wants to use it with their Cinder project: https://github.com/angelkatalyst/Cinder-Gamepad

That's great news that you added XInput support. On my backlog of tasks is to add rumble support for the xbox controllers and as far as I understand it can only be accessed with XInput. As part of the code above, there is a VS 2012 and an Xcode project that will build a static library, as well as the already compiled library binaries.

I've got a bunch of wired 360 controllers, I can try to give your new changes a shot soon!

[ThemsAllTook]

So, I think I have proper MSVC support now. This was my first time actually using it, so it's quite likely I've gotten a thing or two wrong, but it builds and runs and appears to work correctly. Here are Windows binaries with the new DInput/XInput stuff, including MSVC .libs:

http://ludobloom.com/temp/gamepad_1.4.0_pre1.zip

That also includes a new version of the test harness, which has a critical memory bug in my XInput code fixed - the one I posted earlier definitely won't work with multiple Xbox controllers, but hopefully this one will.

Here's the full updated project, with source code, MinGW makefile, and MSVC solution included:

http://ludobloom.com/temp/gamepad_1.4.0_pre1_source.zip

I'll wait to update the first post until I've gotten confirmation from a few people that this works, but I'm feeling pretty good about it!

Hey Alex, I wanted to let you know I've been using this gamepad library for about a year now and I really appreciate all the work!

Awesome, glad to hear it!

That's great news that you added XInput support. On my backlog of tasks is to add rumble support for the xbox controllers and as far as I understand it can only be accessed with XInput.

Yep, force feedback is next on my list after I fix the OS X bugs reported in this thread. XInput seems to be the only API that actually supports it well at the moment... It looks like I'm going to be in the realm of sending device-specific escape codes to get it to work elsewhere. Should be interesting and probably hard, but I think it's an important enough thing to be worth the effort.

[look4awhile]

So, I think I have proper MSVC support now.

Builds from the source without any file changes on 64-bit MSVC 2013.
Does not crash anymore.
Not sure about axis ordering. Same controller X and Y axis are flipped vs OSX version.
I.e. axisStates[0] is X on MAC, and Y on Windows.

Is there specific axis ordering we should expect? Perhaps an API to query what's what?

[ThemsAllTook]

Great!

I'll take another look at axis order. With XInput (and to a lesser extent DirectInput), I get to choose it myself, so I'll see if I can match the order to what other platforms report as best I can. With other APIs and controllers, I'm at the mercy of the drivers, which I've found to be very inconsistent - elements are reported in different orders across devices, and even on the same device across platforms.

Once I can call the lower-level stuff done (at the very least I want to get force feedback support in, and possibly LED control so you can do things like change the light bar color on the PS4 controller), my plan is to start working on a higher-level mapping layer that attempts to make sense of the madness and gives some sort of API for consistent mapping. This is going to require gathering a database of layouts for each individual controller on each platform, which will need to be a community effort since I don't have access to every device on the planet... Hopefully I'll be able to get the most popular ones mapped at the start, and the community can help fill in data for the lesser-known ones.

[dynamite-ready]

So, I think I have proper MSVC support now. This was my first time actually using it, so it's quite likely I've gotten a thing or two wrong, but it builds and runs and appears to work correctly. Here are Windows binaries with the new DInput/XInput stuff, including MSVC .libs:

...

I'll wait to update the first post until I've gotten confirmation from a few people that this works, but I'm feeling pretty good about it!

Very much appreciate the resolution of the snprintf stuff.

So I made a quick test...
 
It looks like you've solved the 'single' USB port issue on Windows, but while testing that, I found a far more worrying issue....

When unplugging and re-attaching an official Xbox device (that same fightstick I complained about sometime ago), the Gamepad_numDevices() counts 2 devices instead of one!

Further more, both the name of the stick, and it's behavior changes across the two successive sessions!

Code:

Session 1 - Device Name: XInput Controller

Code:

Session 2 - Device Name: FightingStickEX2 (Arcade Stick)

In session 1, the stick itself appears to register as an array of buttons. But in session 2, the stick works the same as it did in your previous distro.

Anyone else seen anything like this? It's the only bug though.

As always, I'll double check when I get the chance.

...

As for look4awhile's work and the OSX stuff, I'm still stumped.
I'll have to go back and check my OS version number.

For the record, SDL has a similar problem (for me at least, if anyone's having a better experience of it)...
On OSX, you can read IO, but you can't hotplug devices.

[look4awhile]

Hot-plugging XBOX controller on OSX does not work for me either. But I think its a driver issue because other joystick-reporting programs do not support it either. I can double-check with other controller at some point soon.

[look4awhile]

my plan is to start working on a higher-level mapping layer that attempts to make sense of the madness and gives some sort of API for consistent mapping. This is going to require gathering a database of layouts for each individual controller on each platform, which will need to be a community effort since I don't have access to every device on the planet... Hopefully I'll be able to get the most popular ones mapped at the start, and the community can help fill in data for the lesser-known ones.

From user's standpoint I'm very much in favor of console approach to controllers, where there is a list of supported peripherals with guaranteed features.

However, I'm not sure there is enough information on some platforms to even identify a peripheral. For example this is the info i get on OSX. XBOX controller is identified as "Controller" (the same as device->description). Btw, button order matches too so that sorting by name would already be an improvement.



I suspect you gonna end up having to support some sort of configuration presets, and it will be up to the application to provide a way to select or map it. A web-based way to generate a preset would probably be the easiest from the UI standpoint. It would also allow you to keep centralized database around.

[ThemsAllTook]

From user's standpoint I'm very much in favor of console approach to controllers, where there is a list of supported peripherals with guaranteed features.

Yep, for sure! I'd really hate to only support a select few devices, though. My hope with this library is to make it possible to plug in any HID-compatible game controller, and assuming it has enough buttons for the number of controls you need, play any game that uses the library with it. That said, if there are things I can do for certain controllers to make them "just work" with no additional user configuration, that's definitely worthwhile.

However, I'm not sure there is enough information on some platforms to even identify a peripheral.

Fortunately this is one area where drivers are actually consistent - the vendor ID/device ID pair appears to be a reliable way to uniquely identify hardware. I haven't yet run into a situation where they're different across platforms, or where two devices share the same IDs.

[randomshade]

Fortunately this is one area where drivers are actually consistent - the vendor ID/device ID pair appears to be a reliable way to uniquely identify hardware. I haven't yet run into a situation where they're different across platforms, or where two devices share the same IDs.

This has been my experience too, fortunately. The one exception to the "two devices share the same IDs" was with a Wii-U Pro Controller (mayflash adapter) that has explicit DirectInput or XInput modes - the latter returns all identifying properties as a 360 controller. That's generally not a huge deal, except that the triggers return in different ways and thus the mappings aren't exactly the same despite not being able to differentiate the devices :/ The only solution I know of is to ask users to use DirectInput mode when they have the choice in this case (terrible solution, I know.)

Edit: Since you've implemented DInput and XInput side by side (and presumably treat a 360 controller as an XInput device) the above case probably won't be an issue for you, now that I think about it.

[soong]

Hello,

I'm trying to use the Gamepad library in Qt, so I registered a function

Code:

void joystickDeviceAttachedCallback(struct Gamepad_device * device, void * context);

using

Code:

Gamepad_deviceAttachFunc(joystickDeviceAttachedCallback, (void *) 0x1);

but I get the error message

error: cannot convert 'MainWindow::joystickDeviceAttachedCallback' from type 'void (MainWindow:(Gamepad_device*, void*)' to type 'void (*)(Gamepad_device*, void*)'
         Gamepad_deviceAttachFunc(joystickDeviceAttachedCallback, 0x1);

                                                                     ^

so...where did I get wrong?

Thanks.

[ThemsAllTook]

Hello,

I'm trying to use the Gamepad library in Qt, so I registered a function

Code:

void joystickDeviceAttachedCallback(struct Gamepad_device * device, void * context);

using

Code:

Gamepad_deviceAttachFunc(joystickDeviceAttachedCallback, (void *) 0x1);

but I get the error message

error: cannot convert 'MainWindow::joystickDeviceAttachedCallback' from type 'void (MainWindow:(Gamepad_device*, void*)' to type 'void (*)(Gamepad_device*, void*)'
         Gamepad_deviceAttachFunc(joystickDeviceAttachedCallback, 0x1);

                                                                     ^

so...where did I get wrong?

Thanks.

Looks like the issue is using a C++ function pointer where a C one is expected. I don't have enough familiarity with C++ to be sure this is the right answer, but I think you can wrap your joystickDeviceAttachedCallback definition in an extern "C" { ... } block and it'll work correctly?