soong
Level 0
|
|
« Reply #100 on: May 08, 2014, 02:24:04 PM » |
|
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?
I will try this approach. Thanks!
|
|
|
Logged
|
|
|
|
soong
Level 0
|
|
« Reply #101 on: May 08, 2014, 02:27:13 PM » |
|
I tried to define the function as #ifdef __cplusplus extern "C" { #endif void joystickDeviceAttachedCallback(struct Gamepad_device * device, void * context); #ifdef __cplusplus } #endif and also tried to define the function as an static member with static void joystickDeviceAttachedCallback(struct Gamepad_device * device, void * context); and now both lead me to error: undefined reference to `c_dfDIJoystick2'
|
|
|
Logged
|
|
|
|
ThemsAllTook
|
|
« Reply #102 on: May 09, 2014, 12:11:07 AM » |
|
|
|
|
Logged
|
|
|
|
Rusk
Level 1
|
|
« Reply #103 on: May 11, 2014, 07:03:01 AM » |
|
Is there any way you can rewrite the callback to not be a class member function? A standalone function should work fine without converting pointers or wrapping in extern C, right?
Perhaps it is easier to poll the gamepads periodically rather than using callbacks?
|
|
|
Logged
|
|
|
|
Cheesegrater
Level 1
|
|
« Reply #104 on: May 12, 2014, 09:28:50 AM » |
|
Is there any way you can rewrite the callback to not be a class member function? A standalone function should work fine without converting pointers or wrapping in extern C, right?
No, C++ does name mangling on all functions, not just class members. It's how function overloading works.
|
|
|
Logged
|
|
|
|
BorisTheBrave
|
|
« Reply #105 on: May 13, 2014, 01:37:40 PM » |
|
Guys, it's nothing to do with extern C or name mangling. Name mangingling is irrelevant when passing a function pointer, and the signature isn't one of the sort extern C has additional effects on. The problem, like rusk says, is that you are using a class member function pointer. These are not the same as normal function pointers, and cannot be passed to C. But there's a very common idiom for converting, which is the secret of that context argument. You end up doing this a lot when using callbacks from C libraries to C++: class MainWindow { ... void JoystickDeviceAttachedHandler(struct Gamepad_device * device); ... }
// The extern isn't required on most platforms in this case, but good practise. extern "C" { void JoystickDeviceAttachedCallback(struct Gamepad_device * device, void * context) { MainWindow* mainWindow = (MainWindow*)context; mainWindow->JoystickDeviceAttachedHandler(device); } }
// Wherever you are registering the Joystick, I don't know what library this is int main() { MainWindow window; .. // Whatever the registration function is, I guarantee that it will take // an additional argument to pass through as context. RegisterJoystick(&JoystickDeviceAttachedCallback, &window); }
|
|
|
Logged
|
|
|
|
oncer
TIGBaby
Simon Parzer
|
|
« Reply #106 on: December 07, 2014, 03:20:28 AM » |
|
Just wanted to let you know I found a bug in the DInput code of this gamepad library. result = IDirectInputDevice8_GetDeviceData(devicePrivate->deviceInterface, sizeof(DIDEVICEOBJECTDATA), events, &eventCount, 0); if (result == DIERR_INPUTLOST || result == DIERR_NOTACQUIRED) { IDirectInputDevice8_Acquire(devicePrivate->deviceInterface); result = IDirectInputDevice8_GetDeviceData(devicePrivate->deviceInterface, sizeof(DIDEVICEOBJECTDATA), events, &eventCount, 0); } if (result != DI_OK) { removeDevice(deviceIndex); deviceIndex--; continue; } If the method succeeds, the return value is DI_OK or DI_BUFFEROVERFLOW. If the method fails, the return value can be one of the following error values: DIERR_INPUTLOST, DIERR_INVALIDPARAM, DIERR_NOTACQUIRED, DIERR_NOTBUFFERED, DIERR_NOTINITIALIZED. Using a Sony DS4 controller connected to the PC, the DI_BUFFEROVERFLOW happens regularly when using both analogue sticks at the same time. The DS4 controller is very common, as ist comes with the PS4 and a lot of people actually use it on their PC, too. In our games we display a popup menu when the main controller gets disconnected so a new controller can be selected. With the DS4 this popup appears randomly and kind of breaks the game. Changing the if (result != DI_OK) to if (SUCCEEDED(result)) fixes the problem. I had to register on this site to make this bug report, which is a minor hassle. Since it is open source, I would suggest uploading the code to a site like github so people can contribute more easily.
|
|
|
Logged
|
|
|
|
ThemsAllTook
|
|
« Reply #107 on: December 07, 2014, 10:53:25 AM » |
|
Thanks for the report, I'll look into it. I know this forum thread isn't an ideal home for the library; it'll be moved somewhere more permanent soon!
|
|
|
Logged
|
|
|
|
photex
|
|
« Reply #108 on: February 10, 2015, 02:29:52 AM » |
|
+1 for moving this to github or bitbucket.
|
|
|
Logged
|
|
|
|
looki
Level 0
|
|
« Reply #109 on: April 14, 2015, 11:00:06 AM » |
|
Yes, PLEASE move this code to a public repository. This library is really great, but I just realized that you're never calling the attach callback on Windows. To add this you need to modify two locations by adding this code below them: if (Gamepad_deviceAttachCallback != NULL) { Gamepad_deviceAttachCallback(deviceRecord, Gamepad_deviceAttachContext); } This goes right below registeredXInputDevices[playerIndex] = deviceRecord; for XInput, and devices[numDevices++] = deviceRecord; for DirectInput I'd also like to submit Windows-specific code for storing the device's guidProduct field. It's what's used by SDL to identify gamepads and part of https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt
|
|
« Last Edit: April 16, 2015, 08:21:12 AM by looki »
|
Logged
|
|
|
|
ThemsAllTook
|
|
« Reply #110 on: April 14, 2015, 12:42:21 PM » |
|
Yikes, that's quite a bug. Thanks for the fix. Since I've put it off for so long, I'm going to dedicate my evening to finding a home outside this thread for the library. Bug me again if I don't post about it within the next few days.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #111 on: April 14, 2015, 02:15:58 PM » |
|
Yeah if you could put it on github/bitbucket that would be great. I've been using it a little for my fighting game but switched back for GLFW just to reduce the number of libraries for now. I may return to using it again though if GLFW's support isn't adequate.
|
|
|
Logged
|
|
|
|
|
ThemsAllTook
|
|
« Reply #113 on: April 18, 2015, 11:06:11 AM » |
|
So, originally I was dead set against github because every experience I've had with git has been completely unbearable. However, I did some research and found out that github has an svn bridge built into every repository. I think it might actually suit my needs after all. I've put the project up here: https://github.com/ThemsAllTook/libstem_gamepadAll I've done so far is import from my personal repository. It's probably not in a state where it can actually be compiled right now (via the makefile, at least; the MSVC project might still work), so I still have a lot of work to do. As soon as it's slightly more presentable, I'll update the first post with the link, and it'll become the official home for the library. I'm totally new to github, so if any of you with more experience spot any glaring errors on the project page, please let me know!
|
|
|
Logged
|
|
|
|
|
ThemsAllTook
|
|
« Reply #115 on: June 30, 2015, 03:27:56 PM » |
|
Someone e-mailed me asking about this and made me feel guilty for leaving it broken as long as I have, so I cleaned up the github project to a state where it should be compilable on other people's computers. I've updated the first post with the github project link and the latest binaries.
Thanks for the README.md suggestion; I'll look into markdown when I get a chance to update the readme.
|
|
|
Logged
|
|
|
|
|