Add gamepad support to woodeneye-008 #14167
Conversation
|
This needs to be adjusted to match the SDL coding style. |
Could you clarify what needs changing? |
|
What I had in mind while writing the original example was to convey the following two messages to anyone reading the code:
While adding additional device support is technically an improvement, the extra complexity adds a little bit of additional cognitive load to the reader of the example, while not conveying the strictly minimum requirement. It also somewhat distracts from the uniqueness of mouse/keyboard splitscreen, I’d opine that a pointed omission of joystick support actually showcases the mouse/keyboard functionality better by distancing itself from traditional joystick implementation paradigms. I think multi-joystick would be better suited to a separate standalone demo, maybe one with a top down cooperative platformer format. It would also better show off the analog directional capabilities of the thumb sticks instead of shoehorning them into a WASD control scheme. |
|
That's fair feedback, and since @ccawley2011 seems to be away, I'll go ahead and close this for now. |
|
I probably ought to mention that the main reason for this PR is to better support systems like the 3DS, which doesn't have a keyboard and therefore requires this PR in order to allow input to work at all. |
In that case, can you clean up this PR based on our feedback, and I'll go ahead and merge it? |
icculus
force-pushed
the
woodeneye-gamepad
branch
from
10920b3 to
5db327a
Compare
This matches the standard for console FPS titles.
This prevents an idle gamepad from overriding mouse input.
|
I rebased this to the latest in revision control and fixed up some things based on feedback. Can y'all take another look over this and see if it's ready to merge? |
| const Uint64 now = SDL_GetTicks(); | ||
| int i; | ||
|
|
||
| if ((now - gamepad_update_ticks) >= 16) { /* only update joysticks at about 60Hz so framerate doesn't matter. */ |
There was a problem hiding this comment.
Should just forward dt_ns to the gamepad function which multiplies it by the desired angular velocity to get the targeted angular displacement in floats, and the function should return two floats representing residual angles to be carried over next frame, saved as extra fields in the player struct.
| } | ||
| break; | ||
| } | ||
|
|
There was a problem hiding this comment.
Just get rid of dpad events entirely, use the left stick for analog movement instead.
| } | ||
| } | ||
|
|
||
| static void updatePlayerGamepad(Player *player) |
There was a problem hiding this comment.
I suggest have this function also handle the left stick to save a 2d direction as an extra field in the player struct representing the current frame’s intended joystick input, akin to how WASD is sampled each frame. It should then be combined with the normalized WASD vector to calculate the final X and Z acceleration
|
Still feels kinda shoehorned, I wonder if it could be simpler if joystick is made mutually exclusive with mkb, and have a unified sample_inputs function that returns two vectors representing the intended movement magnitude and the integrated angular displacement? it also feels like it’s just not a very good showcase of joystick usage in general, I have something sketched up in mind of a separate example that I think would work better as demonstration of how to utilize joysticks. |
I have no ego in this (and I assume @ccawley2011 doesn't either)...take a totally different approach and I'll happily close this PR unmerged. :) |
5 participants
No description provided.