19

What is the relationship between SDL_Joystick and SDL_GameController? These are the only things I know of right now:

  • SDL_GameController and related functions are all part of a new API introduced in SDL2.
  • SDL_GameController and related functions are built on top of the existing SDL_Joystick API.
  • (Working Draft) You can obtain an instance of SDL_Joystick by calling on the function SDL_GameControllerGetJoystick() and passing in an instance of SDL_GameController.
  • (Working Draft) You can obtain an instance of SDL_GameController first by calling on SDL_JoystickInstanceID() and passing in an instance of SDL_Joystick, then pass in the SDL_JoystickID to SDL_GameControllerFromInstanceID.

Even though SDL_Joystick and SDL_GameController are both interchangeable, it seems like SDL_GameController is here to replace and slowly succeed the SDL_Joystick.

Reason is, when polling for SDL_Event, the SDL_Event instance contains both the SDL_Event::jbutton and SDL_Event::cbutton structs, representing the SDL_Joystick buttons and SDL_GameController buttons, respectively. I guess I can use either one, or both, button events for the player controls.

I could be wrong here.

I would like to ask:

  • What are the differences between SDL_Joystick and SDL_GameController?

  • Is SDL_Joystick now referring to this controller?

    enter image description here

    And the same for SDL_GameController?

    enter image description here

  • What are the advantages/disadvantages of using SDL_Joystick over SDL_GameController (and vice versa)?

genpfault
  • 51,148
  • 11
  • 85
  • 139
tom_mai78101
  • 2,383
  • 2
  • 32
  • 59
  • Your description sounds just about right. Joystick is a bit lower level - there are buttons, axes and huts, but it may represent any configuration. Gamepad is much more constrained, with SDL implementation being modeled around xbox gamepad (e.g. borrowing button names from it), but it matches popular gamepad models and even have a database of presets and [configuration tools](http://generalarcade.com/gamepadtool/) to remap some weird gamepads. That way you can make assumptions about axes/buttons, while user can use remapping tool to configure it. – keltar Apr 25 '18 at 13:59
  • @keltar So, if I were to imagine the SDL implementation like a C++ object-oriented design, `SDL_Joystick` is the parent class of `SDL_GameController`? – tom_mai78101 Apr 25 '18 at 14:06
  • In a way, yes. It watches for joystick events and generates gamecontroller events from them. – keltar Apr 25 '18 at 14:59
  • @keltar Thanks. I also found this quote some place else on Google but I lost the link. It said `If you use SDL_GameController in a game instead SDL_Joystick, you'll have the same button mapping on every device you port your game on.` Is this true? – tom_mai78101 Apr 25 '18 at 15:11
  • 1
    Yes and no. SDL have builtin mappings for popular models, but "every device" part is unrealistic. However users themselves can configure their device mapping (and upload it for others to use, if desired) without modifying the game, since remapping files can be loaded via environment variables. So in some sense you can ignore remapping problem, delegating it to end users themselves. – keltar Apr 25 '18 at 15:17

1 Answers1

10

First of all, SDL game controllers are the extension of SDL joystics (for the scope of this answer when I say "controller" or "joystick" I mean SDL's implementation, not hardware device category in general). As wiki says,

This category contains functions for handling game controllers and for mapping joysticks to game controller semantics. This is built on top of the existing joystick API.

If you are running your game from Steam, the game controller mapping is automatically provided for your game.

Internally SDL uses joystic events and processes them to produce game controller events according to controller mapping. Hence one may say that joystic is lower level thing while game controller is a generalisation upon joysticks to produce more predictable/compatible (but more constrained) for games that wants gamepad-like input devices.

With game controller, you can program input for just one xbox-like controller thing, and SDL will make user's controller compatible with that (sometimes with the user's help - there are way too many different controllers, we can't possibly expect SDL to have configurations for all of them). Of course if controller is very different (or not controller at all - e.g. fly simpulation sticks, wheels, etc.), that would be problemmatic.

Basically game controller provides xbox-like buttons and axes for user side, freeing application developer from the need to support controller remapping - as remapping is done in SDL itself. For some popular controllers SDL already have builtin mappings, and for others user-defined mapping can be loaded via environment variable.

There is also a configuration tool that simplifies remapping for end user, including exporting resulting configuration to said environment variable. Steam also have builtin configuration tool, which configuration it (supposedly - I've never used that) exports to SDL - essentially making users themselves responsible for configuring their controllers.

keltar
  • 17,711
  • 2
  • 37
  • 42