The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
SDL_Controller design
Ed Phillips
Guest

Hello,

I think I'm missing something when it comes to the basic reasoning behind
the design of the SDL_Controller stuff, and the documentation on the Wiki
that I can see doesn't go into any discussion on the design decisions.

When I first looked at the "mapping" capabilities of SDL_Controller, I
thought, HEY!, this was a way to give names to each of the buttons/axes on
any device, so you can pass them through to the application/game and it
can present these names to the user when they are setting up their
controller configuration. Cool! Oh look, they already have a database of
these name mappings! Great!

However, the more I started looking at it, I began to see that this is not
the case at all. It seems to be a way to turn the raw button/axis numbers
on a non-XInput device into an XInput control like "leftshoulder" or
"righty"?

So really, this is just a way to make every controller work like an XBox
controller (even if it doesn't have the same physical controls or the same
names on the buttons, etc.), and doesn't really address the issue of
mapping the names of the actual physical controls on a particular device
to the button/axis numbers normally received in SDL_Joystick calls?

I guess if you don't want your game/application to treat every device like
an XBox 360 Controller, then the SDL_Controller stuff is not for you?

How does Steam's controller API play into things? There is mention of
Steam here (and nowhere else I can find):

http://wiki.libsdl.org/CategoryGameController

It states:

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

I'm not sure what that means. Steam controller mappings take a list of
"actions" defined for a game, and allow the developer and/or user to
configure which controls on their devices will invoke these actions. A
game using the controller API will see "actions" and not raw inputs... so
I'm not sure how the SDL_Controller stuff plays into this. Also, in order
to use the Steam controller API, you have to call functions in the Steam
runtime, and I'm not sure if SDL can/would be doing that, and it won't
provide an SDL_Controller mapping.

Any help regarding these concepts would be greatly appreciated!

Thanks,

Ed

Ed Phillips University of Delaware (302) 831-6082
Systems Programmer IV, Network and Systems Services
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_Controller design
Daniel Gibson
Guest

Hi Ed,

SDL_GameController is for game controllers aka gamepads, which tend to
be similar to the xbox360 or PS2/3/4 pad (one DPAD on the left, two
analog sticks, 4 buttons for the right thumb, 2 shoulder buttons on each
side that may be trigger axes and those "back" and "start" buttons in
the middle, maybe even an "xbox" button or similar).
I think the main purposes are
1. making it easy(er) to port XInput code to SDL, esp. for Linux/Mac
2. allowing game developers to set default bindings for gamepads that
make sense with most gamepads.

Usually you use SDL_GameController with the corresponding events
(SDL_CONTROLLER*), I think, but you *can* also use it to set the
displayed names etc of normal SDL_Joystick buttons, if the joystick
happens to be a known game controller.
SDL_IsGameController(joystick) tells you if a joystick is a know game
controller, SDL_GameControllerGetBindForAxis() and
SDL_GameControllerGetBindForButton() tell you how things are mapped.
(I've used it that way so I don't have to handle game controller events
separately, but still get the mapping)

Regarding Steam: The documentation is referring to the gamepad
configuration in the Steam (Linux?) Big Picture settings, that lets you
create a mapping from your gamepad's buttons/axes to the xbox controller
model. I think Steam then sets the SDL_GAMECONTROLLERCONFIG environment
variable with the mapping string, which SDL2 then uses for games that
use SDL2 and are launched from Steam.

So "mapping" refers to "Button 3 corresponds to SDL_CONTROLLER_BUTTON_A,
Axis 2 corresponds to SDL_CONTROLLER_AXIS_RIGHTX" and so on, not to
standard actions.
No idea if standard action mappings are available on Steam/Linux, but if
they are that's something provided by Steamworks SDK, not by SDL2.

BTW:
https://joostdevblog.blogspot.de/2012/08/the-craziness-that-is-joysticks-on-pc.html
is an interesting read about how handling joysticks and similar input
devices sucks (only difference is that now with SDL2 it's a a bit better
for gamepads).

Cheers,
Daniel

On 01.12.2016 18:22, Ed Phillips wrote:
Quote:
Hello,

I think I'm missing something when it comes to the basic reasoning
behind the design of the SDL_Controller stuff, and the documentation on
the Wiki that I can see doesn't go into any discussion on the design
decisions.

When I first looked at the "mapping" capabilities of SDL_Controller, I
thought, HEY!, this was a way to give names to each of the buttons/axes
on any device, so you can pass them through to the application/game and
it can present these names to the user when they are setting up their
controller configuration. Cool! Oh look, they already have a database
of these name mappings! Great!

However, the more I started looking at it, I began to see that this is
not the case at all. It seems to be a way to turn the raw button/axis
numbers on a non-XInput device into an XInput control like
"leftshoulder" or "righty"?

So really, this is just a way to make every controller work like an XBox
controller (even if it doesn't have the same physical controls or the
same names on the buttons, etc.), and doesn't really address the issue
of mapping the names of the actual physical controls on a particular
device to the button/axis numbers normally received in SDL_Joystick calls?

I guess if you don't want your game/application to treat every device
like an XBox 360 Controller, then the SDL_Controller stuff is not for you?

How does Steam's controller API play into things? There is mention of
Steam here (and nowhere else I can find):

http://wiki.libsdl.org/CategoryGameController

It states:

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

I'm not sure what that means. Steam controller mappings take a list of
"actions" defined for a game, and allow the developer and/or user to
configure which controls on their devices will invoke these actions. A
game using the controller API will see "actions" and not raw inputs...
so I'm not sure how the SDL_Controller stuff plays into this. Also, in
order to use the Steam controller API, you have to call functions in the
Steam runtime, and I'm not sure if SDL can/would be doing that, and it
won't provide an SDL_Controller mapping.

Any help regarding these concepts would be greatly appreciated!

Thanks,

Ed

Ed Phillips University of Delaware (302) 831-6082
Systems Programmer IV, Network and Systems Services
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_Controller design
Alex Szpakowski
Guest

The SDL_GameController API is so your code can determine that e.g. the left trigger on a controller is held down, no matter what controller-like device is used and no matter what OS or drivers are used (for example the button and axis indices reported by the Xbox 360 controller on Windows are different than those reported when using the Tattiebogle driver for the 360 on macOS).

The latest SDL source code has an API in SDL_Joystick to get the vendor and product IDs of a joystick. That’s what you’d want to use if you want to display different button prompts (images and text) depending on what controller is actually used.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org