PistonDevelopers
Controller ids design
We have the following scenarios:
- Some controllers allow you to press an axis as a button. Other controllers might allow you to press and pull an axis, so it is not necessarily just one button id per axis id.
- One window back-end might treat the button id separately from axis ids, while another might use the same ids for buttons and axis motion.
- Different APIs might use different orders for ids. For example, left/right/up/down vs up/down/left/right.
- The orientation of a device might affect the meaning of a button/axis. For example, a tablet with physical buttons might change the "up" button to "right" depending on an orientation sensor. It also might happen that the id remains the same and must be changed in application depending on orientation.
- Another orientation change is that the player changes orientation, for example in space where there is no "up" when using a device attached to a wall.
- A third type of orientation change is different frame of references between players using the same buttons. For example, players sitting around a table and using a device on the table.
- Physical grouping of devices per player might change. For example, a helmet and a gun controller might be used by one player, but assigned different ids. The opposite case is also possible, where the helmet and gun share the same id.
- A game might be paused, then swapping physical devices between the player or arrange a different grouping.
- A device might be unplugged and then another inserted, given the same id.
To solve this, the Piston core makes the following assumptions:
- The button ids are separated from axis motion ids. A window back-end might use the same ids, but this is not guaranteed.
- There are no reserved button ids. All ids are unknown to the core, so it does not know which id is the "left button" on a joystick.
- The orientation of a device is unknown.
- Physical grouping of devices per player is unknown.
- The physical device usually corresponds to a joystick id, but this is not guaranteed
Swapping window back-end
When changing from one window back-end to another, it is not guaranteed that the physical meaning of the controller devices remains the same. Player configurations might brake when changing window back-end.
Changes while using the software
Controllers are usually plug-in devices and might be added/removed or swapped while running an application.
Controller library design
To write a reusable library for Piston, is is necessary to allow changing the mapping from one button or axis motion to another. This is because the ids might change depending on the window back-end or the physical device.
Trying to sanely handle the complexity of HID gamepads/joysticks across platform is really hard. I've been trying to get something useful spec'ed in the W3C Gamepad API spec for years and haven't managed to do it. Since you're just implementing a library and not a spec with multiple implementations you can probably do better. :)
The SDL_GameController APIs are not a terrible place to start. Writing something that has a similar design might make it possible to reuse people's existing SDL controller mappings (which they're likely to have if they use Steam).
