next »

[soong]

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!

[soong]

I tried to define the function as

Code:

#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

Code:

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

and now both lead me to

error: undefined reference to `c_dfDIJoystick2'

[ThemsAllTook]

Some good info here that might help you:
http://stackoverflow.com/questions/19808054/convert-c-function-pointer-to-c-function-pointer
http://www.parashift.com/c++-faq/memfnptr-vs-fnptr.html

[Rusk]

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?

[Cheesegrater]

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.

[BorisTheBrave]

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++:

Code:

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);
}

[oncer]

Just wanted to let you know I found a bug in the DInput code of this gamepad library.

Code:

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.

[ThemsAllTook]

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!

[photex]

+1 for moving this to github or bitbucket.

[looki]

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:

Code:

if (Gamepad_deviceAttachCallback != NULL) {
    Gamepad_deviceAttachCallback(deviceRecord, Gamepad_deviceAttachContext);
}

This goes right below

Code:

registeredXInputDevices[playerIndex] = deviceRecord;

for XInput, and

Code:

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

[ThemsAllTook]

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. 

[InfiniteStateMachine]

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.

[looki]

Cool, thanks! By the way, I was stupid and passed the *remove* context to the attach callback. Make sure not to copy my mistake 

[ThemsAllTook]

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_gamepad

All 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!

[Cheezmeister]

Not a glaring error, really, but it's in vogue to substitute README.md for ReadMe.txt and use Markdown. `backticks` for code and ##Hashes for headings make it easier to grok on the web UI. You can even get real fancy and [hyperlink directly](https://github.com/ThemsAllTook/libstem_gamepad/blob/master/source/gamepad/Gamepad.h#L68) to the functions to which you refer.

[ThemsAllTook]

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.