The issue comes with the migration to SDL2. SDL2 uses Xinput library for Windows and it works different from old mm and dinput libraries.
To mitigate this issue SDL2 implements a new Game Controller API. This new API use a intermediate file (gamecontrollerdb.txt) where the joysticks are mapped to follow a similar configuration than Xbox 360 game controller.
To perform this mapping there are several tools availables (Steam Big Mode, controllermapping in SDL2 test sources and antimicro).
I have tested this patch in Linux/Windows with a Xbox 360 controller and a PS2 clone. Xbox 360 worked out the box and for the PS2 clone I had to do the mapping using a controllermapping program. After this, it works like a charm. The behaviour was consistent between linux and windows (not as now).
This patch is NOT BACKWARD COMPATIBLE due to new API. Between other things the new API has not "hat" concept and it processes "hat/dpad" control as any other button (BUTTON_DPAD_UP, BUTTON_DPAD_DOWN, BUTTON_DPAD_LEFT and BUTTON_DPAD_RIGHT). Also, it implement Shoulder trigger buttons (left/right) as independent axis.
Moreover, to implement a "do_version" it is very hard because we would have to differentiate between MacOS&Linux and Windows, and between Joysticks and Game Controllers. The only way to make it compatible with previous versions is to compile SDL2 disabling XINPUT and enabling MM/DINPUT but this way we would loose hottpluggin, haptic (vibration) and standatization (at last) features.
To clarify a little how it works now regarding our unintuitive Joystick sensor:
A Game Controller is composed of:
6 axis availables (in order from 0 to 5):
AXIS_LEFTSTICK_X, AXIS_LEFTSTICK_Y, AXIS_RIGHTSTICK_X, AXIS_RIGHTSTICK_Y, AXIS_TRIGGERLEFT and AXIS_TRIGGERRIGHT.
and 15 buttons availables (in order from 0 to 14):
BUTTON_A, BUTTON_B, BUTTON_X, BUTTON_Y, BUTTON_BACK, BUTTON_GUIDE, BUTTON_START, BUTTON_LEFTSTICK, BUTTON_RIGHTSTICK, BUTTON_LEFTSHOULDER, BUTTON_RIGHTSHOULDER, BUTTON_DPAD_UP, BUTTON_DPAD_DOWN, BUTTON_DPAD_LEFT and BUTTON_DPAD_RIGHT.
Then with a game controller we would expect the following behaviour:
- Event type = Single Axis:
- "Index" means joystick/device
- Axis Number 1 -> Left Stick horizontal movement
- Axis Number 2 -> Left Stick vertical movement
- Axis Number 3 -> Right Stick horizontal movement
- Axis Number 4 -> Right Stick vertical movement
- Axis Number 5 -> Left Shoulder trigger movement
- Axis Number 6 -> Right Soulder trigger movement
- Event type = Hat:
There is no Hat concept in new game controller API. It is treaty as a normal button
- Hat Number 1 or 2 (left or right) -> Only Hat Number 1 is simulated through the buttons
- Hat direction (8 directions) -> Now you only have 4 buttons (BUTTON_DPAD_UP, BUTTON_DPAD_DOWN, BUTTON_DPAD_LEFT and BUTTON_DPAD_RIGHT), if you want to check a diagonal direction (i.e top/left) you will have to add 2 sensors (BUTTON_DPAD_LEFT and BUTTON_DPAD_UP) with an AND controller to simulate the same behaviour.
Having said that, this mode will not work in current patch.
- Event type = Axis
Similar to Single Axis mode but taken the Axis in pairs and after splitting them in 4 directions (Up/Down/Left/Right).
- Axis Number 1 -> Left Stick (Up/Down/Left/Right)
- Axis Number 2 -> Right Stick (Up/Down/Left/Right)
- Axis Number 3 -> Both Shoulder triggers. Left/Right -> Left trigger (active when unpressed / active when pressed), Up/Down Right trigger (active when unpressed / active when pressed).
- Event type = Button
- Button number 0 -> BUTTON_A
- Button number 1 -> BUTTON_B
- Button number 2 -> BUTTON_X
- Button number 3 -> BUTTON_Y
- Button number 4 -> BUTTON_BACK
- Button number 5 -> BUTTON_GUIDE
- Button number 6 -> BUTTON_START
- Button number 7 -> BUTTON_LEFTSTICK
- Button number 8 -> BUTTON_RIGHTSTICK
- Button number 9 -> BUTTON_LEFTSHOULDER
- Button number 10 -> BUTTON_RIGHTSHOULDER
- Button number 11 -> BUTTON_DPAD_UP
- Button number 12 -> BUTTON_DPAD_DOWN
- Button number 13 -> BUTTON_DPAD_LEFT
- Button number 14 -> BUTTON_DPAD_RIGHT
TODO:
- I have no tested in MacOsX yet