New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add direct support for gamecontrollerdb #900

Closed
CreamyCookie opened this Issue Nov 20, 2016 · 21 comments

Comments

Projects
None yet
4 participants
@CreamyCookie

CreamyCookie commented Nov 20, 2016

Currently using the gamecontrollerdb might not even be possible as "as the joystick functions don't expose POVs separately from buttons (or axes, in the case of the Linux 360 controller driver)."

Additionally to that we need a method to get the GUID of a joystick, which gamecontrollerdb uses to differentiate between joysticks with the same name. Note that the GUID's there may be changing soon: gabomdq/SDL_GameControllerDB#110

Preferably this should support both polling and events.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Dec 3, 2016

Member

The "joystick" functions don't expose POVs or GUIDs but GLFW uses the same underlying APIs as SDL2, so the GLFW internals will push the native data to both the "joystick" and "controller" logic and each will translate and present it after its own fashion.

Member

elmindreda commented Dec 3, 2016

The "joystick" functions don't expose POVs or GUIDs but GLFW uses the same underlying APIs as SDL2, so the GLFW internals will push the native data to both the "joystick" and "controller" logic and each will translate and present it after its own fashion.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jan 6, 2017

Member

This work has begun in the gamecontrollerdb branch.

Member

elmindreda commented Jan 6, 2017

This work has begun in the gamecontrollerdb branch.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Mar 6, 2017

Member
  • Joystick state handled by shared code
  • Support for joystick hats
  • Support for joystick GUIDs
  • THE GREAT AND HORRIFYING SDL2 ELEMENT ORDER MATCHING
  • Support for hats on Linux
  • SDL_GameControllerDB parsing
  • Element remapping logic
  • Public gamepad state struct
  • Public gamepad functions
Member

elmindreda commented Mar 6, 2017

  • Joystick state handled by shared code
  • Support for joystick hats
  • Support for joystick GUIDs
  • THE GREAT AND HORRIFYING SDL2 ELEMENT ORDER MATCHING
  • Support for hats on Linux
  • SDL_GameControllerDB parsing
  • Element remapping logic
  • Public gamepad state struct
  • Public gamepad functions
@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jun 23, 2017

Member

Parsing, matching, remapping and state retrieval are working. There's still a little work left to do, but most of it is done.

Below is the raw state of an Xbox 360 controller on Linux (top) and filtered through a mapping (bottom) from the current gamecontrollerdb.txt file.

mapping

The current (but not necessarily final) API is as follows:

#define GLFW_GAMEPAD_DPAD_UP        0
#define GLFW_GAMEPAD_DPAD_RIGHT     1
#define GLFW_GAMEPAD_DPAD_DOWN      2
#define GLFW_GAMEPAD_DPAD_LEFT      3
#define GLFW_GAMEPAD_A              4
#define GLFW_GAMEPAD_B              5
#define GLFW_GAMEPAD_X              6
#define GLFW_GAMEPAD_Y              7
#define GLFW_GAMEPAD_LEFT_THUMB     8
#define GLFW_GAMEPAD_RIGHT_THUMB    9
#define GLFW_GAMEPAD_LEFT_BUMPER    10
#define GLFW_GAMEPAD_RIGHT_BUMPER   11
#define GLFW_GAMEPAD_START          12
#define GLFW_GAMEPAD_BACK           13

#define GLFW_GAMEPAD_LEFT_X         0
#define GLFW_GAMEPAD_LEFT_Y         1
#define GLFW_GAMEPAD_RIGHT_X        2
#define GLFW_GAMEPAD_RIGHT_Y        3
#define GLFW_GAMEPAD_LEFT_TRIGGER   4
#define GLFW_GAMEPAD_RIGHT_TRIGGER  5

typedef struct GLFWgamepadstate
{
    char buttons[14];
    float axes[6];
} GLFWgamepadstate;

int glfwParseGamepadMapping(const char* string);
int glfwJoystickIsGamepad(int jid);
int glfwGetGamepadState(int jid, GLFWgamepadstate* state);

glfwParseGamepadMapping can handle both a single mapping, multiple mappings separated by newlines and the whole unmodified gamecontrollerdb.txt with comments and everything.

Feedback on the public API is very welcome, including nitpicky feedback, the earlier the better but any time before release works. Also, should it be gamepad or controller?

Member

elmindreda commented Jun 23, 2017

Parsing, matching, remapping and state retrieval are working. There's still a little work left to do, but most of it is done.

Below is the raw state of an Xbox 360 controller on Linux (top) and filtered through a mapping (bottom) from the current gamecontrollerdb.txt file.

mapping

The current (but not necessarily final) API is as follows:

#define GLFW_GAMEPAD_DPAD_UP        0
#define GLFW_GAMEPAD_DPAD_RIGHT     1
#define GLFW_GAMEPAD_DPAD_DOWN      2
#define GLFW_GAMEPAD_DPAD_LEFT      3
#define GLFW_GAMEPAD_A              4
#define GLFW_GAMEPAD_B              5
#define GLFW_GAMEPAD_X              6
#define GLFW_GAMEPAD_Y              7
#define GLFW_GAMEPAD_LEFT_THUMB     8
#define GLFW_GAMEPAD_RIGHT_THUMB    9
#define GLFW_GAMEPAD_LEFT_BUMPER    10
#define GLFW_GAMEPAD_RIGHT_BUMPER   11
#define GLFW_GAMEPAD_START          12
#define GLFW_GAMEPAD_BACK           13

#define GLFW_GAMEPAD_LEFT_X         0
#define GLFW_GAMEPAD_LEFT_Y         1
#define GLFW_GAMEPAD_RIGHT_X        2
#define GLFW_GAMEPAD_RIGHT_Y        3
#define GLFW_GAMEPAD_LEFT_TRIGGER   4
#define GLFW_GAMEPAD_RIGHT_TRIGGER  5

typedef struct GLFWgamepadstate
{
    char buttons[14];
    float axes[6];
} GLFWgamepadstate;

int glfwParseGamepadMapping(const char* string);
int glfwJoystickIsGamepad(int jid);
int glfwGetGamepadState(int jid, GLFWgamepadstate* state);

glfwParseGamepadMapping can handle both a single mapping, multiple mappings separated by newlines and the whole unmodified gamecontrollerdb.txt with comments and everything.

Feedback on the public API is very welcome, including nitpicky feedback, the earlier the better but any time before release works. Also, should it be gamepad or controller?

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Jun 23, 2017

Collaborator

Also, should it be gamepad or controller?

From https://en.wikipedia.org/wiki/Game_controller:

A game controller is a device used with games or entertainment systems to provide input to a video game, typically to control an object or character in the game.

From https://en.wikipedia.org/wiki/Gamepad:

A gamepad (also called joypad or controller), is a type of game controller held in two hands, where the fingers (especially thumbs) are used to provide input.

So, a gamepad is a subset of controllers, it's a specific type.

https://www.googlefight.com/gamepad-vs-controller.php says controller is a much more popular word.

I think it depends on what other controllers are/will be supported.

If this API is very specific to gamepads, then gamepad is probably fine. But if it's going to apply to other types of controllers, then probably going with controller is a better fit.

Also, how does this relate to the existing "joystick" API of GLFW?

(This is a very stereotypical bikeshedding moment... haha.)

Collaborator

dmitshur commented Jun 23, 2017

Also, should it be gamepad or controller?

From https://en.wikipedia.org/wiki/Game_controller:

A game controller is a device used with games or entertainment systems to provide input to a video game, typically to control an object or character in the game.

From https://en.wikipedia.org/wiki/Gamepad:

A gamepad (also called joypad or controller), is a type of game controller held in two hands, where the fingers (especially thumbs) are used to provide input.

So, a gamepad is a subset of controllers, it's a specific type.

https://www.googlefight.com/gamepad-vs-controller.php says controller is a much more popular word.

I think it depends on what other controllers are/will be supported.

If this API is very specific to gamepads, then gamepad is probably fine. But if it's going to apply to other types of controllers, then probably going with controller is a better fit.

Also, how does this relate to the existing "joystick" API of GLFW?

(This is a very stereotypical bikeshedding moment... haha.)

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Jun 23, 2017

Collaborator

Also, how does this relate to the existing "joystick" API of GLFW?

I think I see it now:

int glfwJoystickIsGamepad(int jid);

In that case, going with gamepad is more accurate and precise, as long as this API is only for gamepads and not for other types of controllers.

Collaborator

dmitshur commented Jun 23, 2017

Also, how does this relate to the existing "joystick" API of GLFW?

I think I see it now:

int glfwJoystickIsGamepad(int jid);

In that case, going with gamepad is more accurate and precise, as long as this API is only for gamepads and not for other types of controllers.

@CreamyCookie

This comment has been minimized.

Show comment
Hide comment
@CreamyCookie

CreamyCookie Jun 25, 2017

@elmindreda Great work! The API looks nice. :)

I don't mind the way it's now, but maybe the constants could start with GLFW_GAMEPAD_BUTTON_ and GLFW_GAMEPAD_AXIS_ respectively to make it even more obvious that they belong to two different categories.


This is probably really obvious, but I just want to restate why I think some kind of unique identifier for the controller (for example "$controllerName:$GUID") is important. Given that the GUID differs, one could store and restore the controller configuration (e.g. moveUp=GLFW_GAMEPAD_DPAD_UP, useItem=GLFW_GAMEPAD_A) for each controller, even if they're both called "Xbox controller". Each player would automatically be assigned their personal config, which is useful if players have different tastes for how to control their character (or vehicle).

Of course, if the controllers have different names, that (personal configs) are already possible. And if both players have controllers with the exact same name and GUID, then I guess there's no way around asking them who is who.

CreamyCookie commented Jun 25, 2017

@elmindreda Great work! The API looks nice. :)

I don't mind the way it's now, but maybe the constants could start with GLFW_GAMEPAD_BUTTON_ and GLFW_GAMEPAD_AXIS_ respectively to make it even more obvious that they belong to two different categories.


This is probably really obvious, but I just want to restate why I think some kind of unique identifier for the controller (for example "$controllerName:$GUID") is important. Given that the GUID differs, one could store and restore the controller configuration (e.g. moveUp=GLFW_GAMEPAD_DPAD_UP, useItem=GLFW_GAMEPAD_A) for each controller, even if they're both called "Xbox controller". Each player would automatically be assigned their personal config, which is useful if players have different tastes for how to control their character (or vehicle).

Of course, if the controllers have different names, that (personal configs) are already possible. And if both players have controllers with the exact same name and GUID, then I guess there's no way around asking them who is who.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jun 27, 2017

Member

I think it depends on what other controllers are/will be supported.

@shurcooL You can see the full list here. Basically anything that maps at least semi-reasonably to an Xbox controller.

I don't mind the way it's now, but maybe the constants could start with GLFW_GAMEPAD_BUTTON_ and GLFW_GAMEPAD_AXIS_ respectively to make it even more obvious that they belong to two different categories.

@CreamyCookie Yeah, I wrote it that way initially but GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER got pretty long. Still considering it.

This is probably really obvious, but I just want to restate why I think some kind of unique identifier for the controller (for example "$controllerName:$GUID") is important. Given that the GUID differs, one could store and restore the controller configuration (e.g. moveUp=GLFW_GAMEPAD_DPAD_UP, useItem=GLFW_GAMEPAD_A) for each controller, even if they're both called "Xbox controller". Each player would automatically be assigned their personal config, which is useful if players have different tastes for how to control their character (or vehicle).

If you're referring to a unique hardware serial number, that's not exposed via the existing APIs. The GUID mentioned above identifies the make and model. If you mean a way to identify the current connection then the GLFW joystick ID serves just as well.

Member

elmindreda commented Jun 27, 2017

I think it depends on what other controllers are/will be supported.

@shurcooL You can see the full list here. Basically anything that maps at least semi-reasonably to an Xbox controller.

I don't mind the way it's now, but maybe the constants could start with GLFW_GAMEPAD_BUTTON_ and GLFW_GAMEPAD_AXIS_ respectively to make it even more obvious that they belong to two different categories.

@CreamyCookie Yeah, I wrote it that way initially but GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER got pretty long. Still considering it.

This is probably really obvious, but I just want to restate why I think some kind of unique identifier for the controller (for example "$controllerName:$GUID") is important. Given that the GUID differs, one could store and restore the controller configuration (e.g. moveUp=GLFW_GAMEPAD_DPAD_UP, useItem=GLFW_GAMEPAD_A) for each controller, even if they're both called "Xbox controller". Each player would automatically be assigned their personal config, which is useful if players have different tastes for how to control their character (or vehicle).

If you're referring to a unique hardware serial number, that's not exposed via the existing APIs. The GUID mentioned above identifies the make and model. If you mean a way to identify the current connection then the GLFW joystick ID serves just as well.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Jun 27, 2017

Collaborator

I wrote it that way initially but GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER got pretty long. Still considering it.

It's long, but not unreasonable when considered in context of other long names:

GLFW_HAT_RIGHT_DOWN
GLFW_KEY_RIGHT_CONTROL
GLFW_MOUSE_BUTTON_MIDDLE
GLFW_CONTEXT_VERSION_MAJOR
GLFW_COCOA_RETINA_FRAMEBUFFER
GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER

If there are no collisions (at present/in future), you could consider dropping GAMEPAD_ and make it just GLFW_BUTTON_RIGHT_BUMPER (but be very careful with that).

Collaborator

dmitshur commented Jun 27, 2017

I wrote it that way initially but GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER got pretty long. Still considering it.

It's long, but not unreasonable when considered in context of other long names:

GLFW_HAT_RIGHT_DOWN
GLFW_KEY_RIGHT_CONTROL
GLFW_MOUSE_BUTTON_MIDDLE
GLFW_CONTEXT_VERSION_MAJOR
GLFW_COCOA_RETINA_FRAMEBUFFER
GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER

If there are no collisions (at present/in future), you could consider dropping GAMEPAD_ and make it just GLFW_BUTTON_RIGHT_BUMPER (but be very careful with that).

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jun 27, 2017

Member

Minor API addition, separate from the BUTTON_ or no BUTTON_ discussion:

#define GLFW_GAMEPAD_CROSS          GLFW_GAMEPAD_A
#define GLFW_GAMEPAD_CIRCLE         GLFW_GAMEPAD_B
#define GLFW_GAMEPAD_SQUARE         GLFW_GAMEPAD_X
#define GLFW_GAMEPAD_TRIANGLE       GLFW_GAMEPAD_Y
Member

elmindreda commented Jun 27, 2017

Minor API addition, separate from the BUTTON_ or no BUTTON_ discussion:

#define GLFW_GAMEPAD_CROSS          GLFW_GAMEPAD_A
#define GLFW_GAMEPAD_CIRCLE         GLFW_GAMEPAD_B
#define GLFW_GAMEPAD_SQUARE         GLFW_GAMEPAD_X
#define GLFW_GAMEPAD_TRIANGLE       GLFW_GAMEPAD_Y
@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 5, 2017

Member

Another API update.

#define GLFW_GAMEPAD_BUTTON_A               0
#define GLFW_GAMEPAD_BUTTON_B               1
#define GLFW_GAMEPAD_BUTTON_X               2
#define GLFW_GAMEPAD_BUTTON_Y               3
#define GLFW_GAMEPAD_BUTTON_LEFT_BUMPER     4
#define GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER    5
#define GLFW_GAMEPAD_BUTTON_BACK            6
#define GLFW_GAMEPAD_BUTTON_START           7
#define GLFW_GAMEPAD_BUTTON_GUIDE           8
#define GLFW_GAMEPAD_BUTTON_LEFT_THUMB      9
#define GLFW_GAMEPAD_BUTTON_RIGHT_THUMB     10
#define GLFW_GAMEPAD_BUTTON_DPAD_UP         11
#define GLFW_GAMEPAD_BUTTON_DPAD_RIGHT      12
#define GLFW_GAMEPAD_BUTTON_DPAD_DOWN       13
#define GLFW_GAMEPAD_BUTTON_DPAD_LEFT       14
#define GLFW_GAMEPAD_BUTTON_COUNT           15

#define GLFW_GAMEPAD_BUTTON_CROSS       GLFW_GAMEPAD_BUTTON_A
#define GLFW_GAMEPAD_BUTTON_CIRCLE      GLFW_GAMEPAD_BUTTON_B
#define GLFW_GAMEPAD_BUTTON_SQUARE      GLFW_GAMEPAD_BUTTON_X
#define GLFW_GAMEPAD_BUTTON_TRIANGLE    GLFW_GAMEPAD_BUTTON_Y

#define GLFW_GAMEPAD_AXIS_LEFT_X        0
#define GLFW_GAMEPAD_AXIS_LEFT_Y        1
#define GLFW_GAMEPAD_AXIS_RIGHT_X       2
#define GLFW_GAMEPAD_AXIS_RIGHT_Y       3
#define GLFW_GAMEPAD_AXIS_LEFT_TRIGGER  4
#define GLFW_GAMEPAD_AXIS_RIGHT_TRIGGER 5
#define GLFW_GAMEPAD_AXIS_COUNT         6

typedef struct GLFWgamepadstate
{
    char buttons[GLFW_GAMEPAD_BUTTON_COUNT];
    float axes[GLFW_GAMEPAD_AXIS_COUNT];
} GLFWgamepadstate;

int glfwParseGamepadMappings(const char* string);
int glfwJoystickIsGamepad(int jid);
const char* glfwGetGamepadName(int jid);
int glfwGetGamepadState(int jid, GLFWgamepadstate* state);

Something as simple as gamepad.buttons[GLFW_GAMEPAD_BUTTON_X] is now very clear but also very repetitive.

I think I'd prefer something like gamepad.buttons.x, but since we don't have anonymous structs and unions (because Microsoft) we either have to drop the state array or make struct access something like gamepad.buttons.separate.x.

Thoughts?

Member

elmindreda commented Jul 5, 2017

Another API update.

#define GLFW_GAMEPAD_BUTTON_A               0
#define GLFW_GAMEPAD_BUTTON_B               1
#define GLFW_GAMEPAD_BUTTON_X               2
#define GLFW_GAMEPAD_BUTTON_Y               3
#define GLFW_GAMEPAD_BUTTON_LEFT_BUMPER     4
#define GLFW_GAMEPAD_BUTTON_RIGHT_BUMPER    5
#define GLFW_GAMEPAD_BUTTON_BACK            6
#define GLFW_GAMEPAD_BUTTON_START           7
#define GLFW_GAMEPAD_BUTTON_GUIDE           8
#define GLFW_GAMEPAD_BUTTON_LEFT_THUMB      9
#define GLFW_GAMEPAD_BUTTON_RIGHT_THUMB     10
#define GLFW_GAMEPAD_BUTTON_DPAD_UP         11
#define GLFW_GAMEPAD_BUTTON_DPAD_RIGHT      12
#define GLFW_GAMEPAD_BUTTON_DPAD_DOWN       13
#define GLFW_GAMEPAD_BUTTON_DPAD_LEFT       14
#define GLFW_GAMEPAD_BUTTON_COUNT           15

#define GLFW_GAMEPAD_BUTTON_CROSS       GLFW_GAMEPAD_BUTTON_A
#define GLFW_GAMEPAD_BUTTON_CIRCLE      GLFW_GAMEPAD_BUTTON_B
#define GLFW_GAMEPAD_BUTTON_SQUARE      GLFW_GAMEPAD_BUTTON_X
#define GLFW_GAMEPAD_BUTTON_TRIANGLE    GLFW_GAMEPAD_BUTTON_Y

#define GLFW_GAMEPAD_AXIS_LEFT_X        0
#define GLFW_GAMEPAD_AXIS_LEFT_Y        1
#define GLFW_GAMEPAD_AXIS_RIGHT_X       2
#define GLFW_GAMEPAD_AXIS_RIGHT_Y       3
#define GLFW_GAMEPAD_AXIS_LEFT_TRIGGER  4
#define GLFW_GAMEPAD_AXIS_RIGHT_TRIGGER 5
#define GLFW_GAMEPAD_AXIS_COUNT         6

typedef struct GLFWgamepadstate
{
    char buttons[GLFW_GAMEPAD_BUTTON_COUNT];
    float axes[GLFW_GAMEPAD_AXIS_COUNT];
} GLFWgamepadstate;

int glfwParseGamepadMappings(const char* string);
int glfwJoystickIsGamepad(int jid);
const char* glfwGetGamepadName(int jid);
int glfwGetGamepadState(int jid, GLFWgamepadstate* state);

Something as simple as gamepad.buttons[GLFW_GAMEPAD_BUTTON_X] is now very clear but also very repetitive.

I think I'd prefer something like gamepad.buttons.x, but since we don't have anonymous structs and unions (because Microsoft) we either have to drop the state array or make struct access something like gamepad.buttons.separate.x.

Thoughts?

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 5, 2017

Member

The code should now be at the point where you can try it out. See the gamecontrollerdb branch.

Member

elmindreda commented Jul 5, 2017

The code should now be at the point where you can try it out. See the gamecontrollerdb branch.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 5, 2017

Member

Things left to do:

  • Proper solution to applying XInput mappings
  • Generator script for gamecontrollerdb.txt > mappings.h
  • Support for SDL 2.0.5 GUIDs
  • Conversion of older GUIDs to new format
  • Actually readable documentation
Member

elmindreda commented Jul 5, 2017

Things left to do:

  • Proper solution to applying XInput mappings
  • Generator script for gamecontrollerdb.txt > mappings.h
  • Support for SDL 2.0.5 GUIDs
  • Conversion of older GUIDs to new format
  • Actually readable documentation

elmindreda added a commit that referenced this issue Jul 7, 2017

Add support for SDL_GameControllerDB
This adds support for importing and applying mappings from the
SDL_GameControllerDB database.

Related to #900.

elmindreda added a commit that referenced this issue Jul 7, 2017

Add support for SDL_GameControllerDB
This adds support for importing and applying mappings from the
SDL_GameControllerDB database.

Related to #900.
@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 7, 2017

Member

SDL_GameControllerDB support has been merged.

Member

elmindreda commented Jul 7, 2017

SDL_GameControllerDB support has been merged.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 9, 2017

Member

@CreamyCookie Did I misunderstand your question? Do you still want a glfwGetJoystickGUID?

Member

elmindreda commented Jul 9, 2017

@CreamyCookie Did I misunderstand your question? Do you still want a glfwGetJoystickGUID?

@CreamyCookie

This comment has been minimized.

Show comment
Hide comment
@CreamyCookie

CreamyCookie Jul 9, 2017

@elmindreda Oops.. I started writing a response, but got distracted by something and the tab got buried. Anyway:

Do you still want a glfwGetJoystickGUID?

Yes, being able to know the GUID (which identifies the make and model) would be great. It'd allow to automatically use the right setup per controller every time the user starts the game. (e.g. Player 1 wants to use GLFW_GAMEPAD_BUTTON_LEFT_BUMPER for the "inventory" action, the other one wants to use GLFW_GAMEPAD_BUTTON_X.) I think that would be a great experience for the player, if it just works the way they set it up. Unless I'm missing something that's not possible without some unique ID, GUID or otherwise. (Not that it's that bad having to assign it manually every time the game is started, but it's still unnecessary work for the user.)

If you're referring to a unique hardware serial number, that's not exposed via the existing APIs.

If it's possible, a unique hardware serial number that never changes for each controller would be even better for correctly assigning the right controls, so it would work even when the make and model are the same. I guess that's often the case, because players buy another one of the same model if they're happy with it for guests, or they buy them in a bundle from the start.

CreamyCookie commented Jul 9, 2017

@elmindreda Oops.. I started writing a response, but got distracted by something and the tab got buried. Anyway:

Do you still want a glfwGetJoystickGUID?

Yes, being able to know the GUID (which identifies the make and model) would be great. It'd allow to automatically use the right setup per controller every time the user starts the game. (e.g. Player 1 wants to use GLFW_GAMEPAD_BUTTON_LEFT_BUMPER for the "inventory" action, the other one wants to use GLFW_GAMEPAD_BUTTON_X.) I think that would be a great experience for the player, if it just works the way they set it up. Unless I'm missing something that's not possible without some unique ID, GUID or otherwise. (Not that it's that bad having to assign it manually every time the game is started, but it's still unnecessary work for the user.)

If you're referring to a unique hardware serial number, that's not exposed via the existing APIs.

If it's possible, a unique hardware serial number that never changes for each controller would be even better for correctly assigning the right controls, so it would work even when the make and model are the same. I guess that's often the case, because players buy another one of the same model if they're happy with it for guests, or they buy them in a bundle from the start.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 18, 2017

Member

@CreamyCookie Fair enough.

Member

elmindreda commented Jul 18, 2017

@CreamyCookie Fair enough.

@CreamyCookie

This comment has been minimized.

Show comment
Hide comment
@CreamyCookie

CreamyCookie Aug 1, 2017

@elmindreda Just saw that you closed this. So, before I forget, I want to say thank you for GLFW and the gamecontrollerdb support! (and further for adding glfwGetJoystickGUID) Great work! 🖖

CreamyCookie commented Aug 1, 2017

@elmindreda Just saw that you closed this. So, before I forget, I want to say thank you for GLFW and the gamecontrollerdb support! (and further for adding glfwGetJoystickGUID) Great work! 🖖

elmindreda added a commit that referenced this issue Sep 15, 2017

Add CMake target for updating gamepad mappings
This adds the 'mappings' build target that downloads the upstream
gamecontrollerdb.txt file and regenerates the mappings.h header.

Related to #900.
@ChengCat

This comment has been minimized.

Show comment
Hide comment
@ChengCat

ChengCat Mar 6, 2018

Sorry for being nitpicking, but I see an inconsistency in the new gamepad API, which you might be interested.

Currently, at least in glfw3.h, the only API function that returns a (int-represented) bool to indicate error is glfwInit(). It seems to me that returning void would be more consistent for glfwUpdateGamepadMappings and glfwGetGamepadState.

ChengCat commented Mar 6, 2018

Sorry for being nitpicking, but I see an inconsistency in the new gamepad API, which you might be interested.

Currently, at least in glfw3.h, the only API function that returns a (int-represented) bool to indicate error is glfwInit(). It seems to me that returning void would be more consistent for glfwUpdateGamepadMappings and glfwGetGamepadState.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Mar 20, 2018

Member

@ChengCat I agree that the return value of glfwUpdateGamepadMappings isn't very useful. However, the return value of glfwGetGamepadState saves the user having to make a separate call to glfwJoystickIsGamepad and/or glfwJoystickPresent.

Member

elmindreda commented Mar 20, 2018

@ChengCat I agree that the return value of glfwUpdateGamepadMappings isn't very useful. However, the return value of glfwGetGamepadState saves the user having to make a separate call to glfwJoystickIsGamepad and/or glfwJoystickPresent.

@ChengCat

This comment has been minimized.

Show comment
Hide comment
@ChengCat

ChengCat Mar 23, 2018

@elmindreda Thanks for the reply. I don't need a separate call for glfwGetGamepadState in my use case. But I think you are right, and I understand other users may appreciate this. :)

ChengCat commented Mar 23, 2018

@elmindreda Thanks for the reply. I don't need a separate call for glfwGetGamepadState in my use case. But I think you are right, and I understand other users may appreciate this. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment