next »

[winxalex]

I love u man. This is great work order in OS chaos.

[dynamite-ready]

Poking my head back into the brink!

So... I have a shiny new Mac, I've rebuilt my test application, but now appear to be having some trouble porting the Windows stuff across to it. Right now, it's reading the name from the Logitech pad that I have (a Precision), but no I/O. As for my Xbox controller, it's completely dead.

It all works reasonably well on Windows, so I wanted to know if I need to install any generic, or specific drivers on the Mac first before using the library. Or if it should work without needing to install anything first (which means I'm doing something dumb)...

I also have one side issue on Windows...

I can detect when pads are attached and detached, but for some reason, detached pads can only be reattached to the USB port they were first attached to... Does this bug sound familiar?

Other than that, the library is a pleasure to use, sir! 

[ThemsAllTook]

Poking my head back into the brink!

So... I have a shiny new Mac, I've rebuilt my test application, but now appear to be having some trouble porting the Windows stuff across to it. Right now, it's reading the name from the Logitech pad that I have (a Precision), but no I/O.

Hmm! I haven't run into any controllers that behave like that yet. So it shows no gamepad elements at all? Or it detects elements, but they don't do anything when you use the controller?

As for my Xbox controller, it's completely dead.

It all works reasonably well on Windows, so I wanted to know if I need to install any generic, or specific drivers on the Mac first before using the library. Or if it should work without needing to install anything first (which means I'm doing something dumb)...

Yep, Xbox controllers unfortunately don't work out-of-the-box on the Mac. This is what you need: http://tattiebogle.net/index.php/ProjectRoot/Xbox360Controller/OsxDriver

I also have one side issue on Window...
I can detect when Pads are attached and detached, but for some reason, detached pads can only be reattached to the USB port they were first attached to... Does this bug sound familiar?

Strange, I haven't run into that one either. I'm in the process of switching APIs on Windows though, so hopefully this sort of thing will get fixed in the process of that.

[dynamite-ready]

Poking my head back into the brink!

So... I have a shiny new Mac, I've rebuilt my test application, but now appear to be having some trouble porting the Windows stuff across to it. Right now, it's reading the name from the Logitech pad that I have (a Precision), but no I/O.

Hmm! I haven't run into any controllers that behave like that yet. So it shows no gamepad elements at all? Or it detects elements, but they don't do anything when you use the controller?

So yeah... It fully populates the device struct, but no events appear to register when I run the program on a Mac.
I'm still investigating, and won't rule out my idiocy, but pad events register fine on Windows.

Not sure if this Mac issue has anything to do with any recent OSX update, but to double check, I used the old test harness from version 1.10, and that worked fine. So I'm stumped...

For the record, I tend not to use the callback stuff, but instead rely the 'device.axisStates' and 'device.buttonStates' fields directly.
Would that cause a problem?

[ThemsAllTook]

For the record, I tend not to use the callback stuff, but instead rely the 'device.axisStates' and 'device.buttonStates' fields directly.
Would that cause a problem?

Ooh, I think I might know what's going on. If you call Gamepad_processEvents() before reading the axes and buttons, does it work? I changed the way that works recently and may not have fully taken into account the axisStates and buttonStates.

[dynamite-ready]

Ooh, I think I might know what's going on. If you call Gamepad_processEvents() before reading the axes and buttons, does it work? I changed the way that works recently and may not have fully taken into account the axisStates and buttonStates.

Nah. I've been doing that. That's why I suspect the implementation of "Gamepad_processEvents()", and possibly also "Gamepad_detectDevices()" is in someway broken on Mac/OSX.

But I'm still investigating...

I may take a quick look at reverting back to version 1.20, and see if that makes a difference.

[dynamite-ready]

A quick update...

To confirm my suspicions, I ported across my test application to Linux and that works exactly as it does on Windows (with the added bonus of detached gamepads working on different ports). So it looks like a Mac only bug.

I wanted to try and debug the issue, so took a quick peek into the low-level abyss...

It's like that Event Horizon movie.
There's some very scary shit going on in there, but I'll give it a poke and see what happens.

...

Just one more thing while I'm here.

If you're trying this out on Windows, no matter which compiler you use, this library has a dependency on -lwinmm. Something which I've mentioned before.

But further to that, if you're using Microsoft's proprietary C/C++ compiler (most likely via Visual Studio), you're going to need to address two more blockers...

1: On line 29 of 'Gamepad.h' there's an '#include' directive for '<stdbool.h>'... This works fine elsewhere, but borks on the Microsoft compiler, which doesn't have a built in implementation of the method. Fortunately it's very easy to roll your own file. Google "stdbool.h on Windows", and you'll see sum' shit...

2: Similarly, though far more complicated, is the issue related the library's dependency on 'snprintf.c'. Again, supported by the other common compilers, but not on Windows. Here are the details - http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010 - There are a few cross-platform implementations of "snprintf" out there, so you have a choice in that regard. I include it in the main program file, so as to not hack the crazy, badass Gamepad library.

Hope that helps someone to get started with this awesome project.

[Martin 2BAM]

Oh god, this is beautiful

If I have time I'll try to help build an ANE extension around this, so Flash/AIR programmers can use it too.
Did anybody start something like that?

Edit: BTW, SDL2 is now zlib licensed! SDL1 is the LGPL one.

[ThemsAllTook]

But further to that, if you're using Microsoft's proprietary C/C++ compiler (most likely via Visual Studio), you're going to need to address two more blockers...

1: On line 29 of 'Gamepad.h' there's an '#include' directive for '<stdbool.h>'... This works fine elsewhere, but borks on the Microsoft compiler, which doesn't have a built in implementation of the method. Fortunately it's very easy to roll your own file. Google "stdbool.h on Windows", and you'll see sum' shit...

2: Similarly, though far more complicated, is the issue related the library's dependency on 'snprintf.c'. Again, supported by the other common compilers, but not on Windows. Here are the details - http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010 - There are a few cross-platform implementations of "snprintf" out there, so you have a choice in that regard. I include it in the main program file, so as to not hack the crazy, badass Gamepad library.

Cool... I've been trying to get an MSVC-compilable version of the library done in my spare time, but spare time has been hard to come by lately. I'll definitely take care of these things as soon as I can get to it, and investigate the weird stuff you're seeing on the Mac too...

Oh god, this is beautiful

If I have time I'll try to help build an ANE extension around this, so Flash/AIR programmers can use it too.
Did anybody start something like that?

Edit: BTW, SDL2 is now zlib licensed! SDL1 is the LGPL one.

Thanks! I don't think such a thing exists yet, but it'd be great to have. Definitely post here when/if you get anywhere with it.

[Xienen]

So, I just grabbed the source files and dropped it into my Cocos2d-x project that I'm aiming at Windows, Mac, and Linux.  I hooked it right into my pre-existing input system that I already had to pull over to add keyboard support to the engine.  I changed the files from .c to .cpp, pulled out the extern "C" lines, and removed the <stdbool.h> as it's no longer needed with .cpp files.

For Visual Studio, to handle the snprintf issue, you can just add some sort of alias to sprintf_s, as they have the exact same syntax.  Since I only need to support Visual C++, I just replaced the few occurrences of snprintf in Gamepad_windows with sprintf_s.

Worked like a charm! Thanks for taking the time to write this and for releasing it open source under zlib. It's a great little library!

[dynamite-ready]

So, I just grabbed the source files and dropped it into my Cocos2d-x...

So... Have you tried it on OSX?

[iforce2d]

It's not a game, but I thought you might like to see I used this to control an RC heli via arduino




Thanks so much for making this available - I've only tried on Linux so far but it worked great, even with my cheap-ass xbox-clone controller.

[Xienen]

So, I just grabbed the source files and dropped it into my Cocos2d-x...

So... Have you tried it on OSX?

Nope, not yet, but getting Mac and Linux running is coming up on my list.

[dynamite-ready]

So no one's tried this on Mac? Apart from the USB slot bug I mentioned earlier (Windows), I can confirm that it all works fine on Windows and Linux (Ubuntu)...

But then where's the fun in targeting those platforms in this day and age, eh? 

[ThemsAllTook]

I'm setting aside some time this week to work on the library, so hopefully I'll be able to at least solve the axisStates/buttonStates problem you're seeing. I'll post here when as soon as there's progress!

[ThemsAllTook]

Oh my. So, I bought a PS4 controller, and this is what it looks like when it's sitting completely still and I'm not touching it at all:



I'm starting to think I might need to include a per-device list of elements to ignore...

[randomshade]

Yeah, we mapped that one a bit back and thought it was interesting. That one has no ill effects for us though, unlike my external webcam which registers as a multiaxis controller and generates axis 0 and axis 1 data for no apparent reason. Based on our mappings every controller has reported axis 0/1 as left stick - is this a universal truth or a bad assumption (and yeah, there is 0 consistency for any other stick/triggers/buttons.)

[Average Software]

Yeah, we mapped that one a bit back and thought it was interesting. That one has no ill effects for us though, unlike my external webcam which registers as a multiaxis controller and generates axis 0 and axis 1 data for no apparent reason. Based on our mappings every controller has reported axis 0/1 as left stick - is this a universal truth or a bad assumption (and yeah, there is 0 consistency for any other stick/triggers/buttons.)

I think my flightstick reports the throttle as axis 0 and the stick as 1/2, but I would have to check.

Either way, I wouldn't make any assumptions at all about what's what,

[randomshade]

Yeah, figured it was a bad assumption. Without that it makes menu navigation to get to the controller mapping require a keyboard which is not ideal but meh I suppose.

[Average Software]

Yeah, figured it was a bad assumption. Without that it makes menu navigation to get to the controller mapping require a keyboard which is not ideal but meh I suppose.

This is why I insist on making controller configuration mouse driven, preferably in a configuration program external to the game.