Improved joystick support #255
Conversation
|
The ramp options in the menu aren't named quite right, since they're really using a polynomial function, not exponential. I'd suggest being more concise and just calling the three options "Linear," "Quadratic," and "Cubic." |
src/platform/DXJoystick.cxx
Outdated
| // ballistics | ||
| x = (x * abs(x)) / 1000; | ||
| y = (y * abs(y)) / 1000; | ||
| if (xAxis == "X") x = float(state.lX) / 1000.0f; |
There was a problem hiding this comment.
lots of superfluous casting here (but at least they are function-style casts and not C-style casts)... the divide by float will do the type promotion, and the type of x will narrow as needed.
|
This project kind of stalled after I learned that one of the most common controllers out there (the Xbox One controller) has triggers which are treated as axes rather than buttons. Our code currently has no support for the concept of an axis triggering a button event, so this makes the triggers on the Xbox One controller basically useless for their intended purpose. Implementing support for an axis to trigger a button would require consideration of actuation point, release point, etc. Expanding the underlying joystick support code is complicated by the number of platform implementations we have on top of it (EvDev, USB, Windows, SDL 1, SDL 2). Development time and available hardware for testing are also scarce resources. Any thoughts on how to move forward would be welcome. One valid option may be to simply merge as-is, and ignore the lack of axis->button support for the time being, since we will be no worse off than we were before this patch. However, the EvDev/USB/Windows joystick code should be updated to use the new floating-point axis readings versus the old integer readings (I believe Windows is done, but may need testing), if any of that code is even connected to anything anymore. |
|
We should remove the non-SDL2 joystick code. That was my plan at least in master once we're done worrying about merging in 2.4 changes. The main reason the Windows joystick code is still in use is because of its Force Feedback support. I do have the start of code that added haptic feedback to our SDL2 joystick code, though. I was considering an analog-to-digital conversion already to handle menu/UI navigation with analog sticks. We could also look into use the GameController API that SDL2 provides which has mappings for various controllers. |
…settings to accommodate variations between devices and users' preferences. Closes BZFlag-Dev#72.
blast007
force-pushed
the
joystick_improvements
branch
from
a43268e
to
69150d2
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This can end up selecting a different joystick than the user had selected if the order of connected joysticks change. However, this matches the logic in SDLJoystick , so it's at least consistent now.
|
That last commit (dcc3d87) fixes my last concern with this PR, which was an issue where the real coordinates and effective coordinates did not always align due to incorrect math. This video shows that the two are now properly aligned (the red/green lines were a temporary visual aid and are not present in the main PR). Due to the math change, a second set of eyes on that commit would be welcome. With that, I believe this is ready to merge assuming no other outstanding concerns. |
This PR implements improved joystick handling per my comments here on issue #72.
This video explains the changes better than I could by typing it out here, so I will leave it at that.
I tested this on my SteelSeries Nimbus, but it would help if anyone with a different model of joystick or controller could also give it a whirl and make sure the effects of the joystick input settings are as expected.