This is a wip branch that adds support for the SDL_Joystick and SDL_GameController sub-systems to T3D: https://github.com/OTHGMars/Torque3D/tree/SDL_Joy_wip
Hopefully with some code-reviews/community input/testing this can be improved and a clean PR made so T3D will have device independent joystick and gamepad support.
To encourage testing, there's a testing module that creates an event viewer gui so you can view events that your devices generate in real-time (it's more fun than stepping through the event loop in the debugger). It also has a settings window so you can see the effect the prefs have on how devices are opened if they are connected or disconnected. After building the engine and installing BaseGame, copy the inputTest directory from Templates/Modules to your game/data directory. It will add a button for the event viewer to the main menu. Please throw any gaming-type input device you have at it and post your results. I do not have any devices with a trackball, so those events are completely untested.
The input model under SDL is different than the existing DInputDevice platform code. Under SDL all input devices other than keyboard/mouse are considered Joysticks. Game Controllers are a subset of Joysticks. The advantage to using Game Controllers is the SDL database of controller mappings. Recognized gamepad devices can be mapped to the xbox input scheme so a single set of ActionMap defaults can be identical buttons on different devices. Additional mappings can be loaded from script or file. More info at https://wiki.libsdl.org/SDL_GameControl ... gsFromFile
There's a new global, $pref::Input::sdlControllerEnabled. If true, any device that SDL recognizes as a Game Controller will be automatically opened as a controller and these events will be used: https://github.com/OTHGMars/Torque3D/bl ... #L392-L430.
The existing global $pref::Input::JoystickEnabled is still used. If true, any device that cannot be recognized as a Game Controller (or all devices if pref::Input::sdlControllerEnabled is false) will be automatically opened as a Joystick and these events will be used: https://github.com/OTHGMars/Torque3D/bl ... #L309-L390.
If both globals are false, no joystick devices will be opened. There is a script interface for opening/closing and getting device details that closely mirrors the SDL_Joystick and SDL_GameController function sets if you do decide to take manual control of opening/closing devices from script.
New events were added for trackballs and the guide button on gamepads.
There are 2 new script callbacks that fire anytime a device is connected or disconnected, onSDLDeviceConnected() and onSDLDeviceDisconneceted(). The connected callback is called before the device is opened by the InputManager so you can modify default behavior if you need to.
Is it possible to use the DECLARE_CALLBACK IMPLEMENT_CALLBACK macros with a class that's not a CONOBJECT? If so, that would be cleaner and easier to document than the current Con::executef() method, but I couldn't figure out how to do it.
Edit: I used the IMPLEMENT_GLOBAL_CALLBACK macro and was able to implement the connect/disconnect callbacks.
I left this enumeration commented out https://github.com/OTHGMars/Torque3D/bl ... pp#L30-L42. It worked as the return value here https://github.com/OTHGMars/Torque3D/bl ... r.cpp#L990, but I could not find the correct way to get the string from the value here https://github.com/OTHGMars/Torque3D/bl ... .cpp#L1044. Lookup is complicated by the fact that the enumeration contains a negative value. So, I went with a simple static lookup function https://github.com/OTHGMars/Torque3D/bl ... er.cpp#L81. I'm looking for suggestions for a better way.
Edit: castConsoleTypeToString() is the function I was looking for.
This if block, https://github.com/OTHGMars/Torque3D/bl ... #L262-L268 could be where it is now, or it could be in the default branch of the switch statement just below it. Is there a preference? Is one better?
Edit: Left as is.
As is sometimes the case with T3D, you go to start something and realize something else needs fixed first. I liked the LOG_INPUT define in the old platform layer, so I defined it when starting on this, but the engine wouldn't build under windows. I 'fixed' that as the first commit. I wouldn't use it anymore since the event monitor gives as much information. But...Since it's in the code, I really should verify it works under Linux or take it back out. I don't have a Linux test environment atm, so if anyone could help out with that, it would be greatly appreciated.
Edit: Removed from the code.
Because of the way they're generalized, these functions https://github.com/GarageGames/Torque3D ... pp#L70-L88 will activate and deactivate the sdl input manager...I'm not sure if duplicates should be made with general names or if it should left as is? If the legacy platform code is going to be depreciated at 4.0 in favor of all sdl, the activation/deactivation could be cleaned up and some functions that only exist to match the old structure could be removed.