Adding game controlers as input method #86
Conversation
|
Nice! |
|
That looks quite good, and should surely work on all platforms! Lemme fix the Windows build issue tomorrow, as the build check workflow is broken (after GitHub Actions Windows runners being broken and then fixed again). You may have to rebase on latest master after the fix is pushed to make the build check work, as the workflow file is used from the branch. |
|
The Windows build check is now fixed. Please rebase onto current master and force-push your branch, then the checks here will probably all be green. |
Using the SDL2 library to use gamecontrollers/joypads as user input method.
nuess0r
force-pushed
the
gamecontrollerinput
branch
from
c6602b4 to
ebb0f1c
Compare
src/RenderLoop.cpp
Outdated
| @@ -30,6 +30,8 @@ void RenderLoop::Run() | |||
|
|
|||
| _projectMWrapper.DisplayInitialPreset(); | |||
|
|
|||
| _controller = _sdlRenderingWindow.FindController(); | |||
There was a problem hiding this comment.
Ideally, store the controller pointer in the SDLRenderingWindow class, call the FindController() method when initializing the subsystem and destroy it if non-zero when uninitializing the subsystem, and move the controller add/remove methods there to keep all the SDL-related resource management in one class, so it better follows a RAII pattern. The actual event handling can still take place in the RenderLoop class. Since the event handler retrieves the controller handle, there's not even a need to add a getter for the pointer, and it can be kept private in the SDLRenderingWindow class just to keep track of the used resource.
| poco_debug(_logger, "No joysticks connected"); | ||
| } | ||
|
|
||
| //For simplicity, we’ll only be setting up and tracking a single |
There was a problem hiding this comment.
If you want, you could also add a setting and an option in the settings dialog to let the user select a specific controller. Then select the stored one automatically on startup, e.g. via its name or device path (which should map to the port it is connected to).
If you're not into Dear ImGui, I can also add this stuff at a later time.
There was a problem hiding this comment.
Didn't knew about Dear ImGui before I had a look at this project. Adding features to the GUI is a bit over my head at the moment (my available time is scrace). Actually I'm not even into C++ but this doesn't hinder me to tinker around :-)
There was a problem hiding this comment.
Sure, no problem! I've got the same time issue, but I'll try my best to spend a bit of it on projectM every week 😀
I'll review the changes this weekend more thoroughly, but at a glance it all looks fine, so expect it to be merged soon!
Thanks again for the contribution!
When you uncommented the existing debug log level example it had no effect because the default level (informative) is set further down in the config file and therefore took priority.
I had a Bluetooth joypad lying around and though that it would be handy to be able to remote control the projectM frontend.
As SDL provides everything needed to handle game controller it was straight forward to add it. I didn't add SDL controller class or so, just extended the SDL window class. Feel free to refactor that if you think this is messy.
Tested on GNU/Linux, Debian Sid, Gnome3
Code comes mainly from this tutorial: https://lazyfoo.net/tutorials/SDL/19_gamepads_and_joysticks/index.php