Skip to content

Add gamepad support to woodeneye-008#14167

Open
ccawley2011 wants to merge 5 commits into
libsdl-org:mainfrom
ccawley2011:woodeneye-gamepad
Open

Add gamepad support to woodeneye-008#14167
ccawley2011 wants to merge 5 commits into
libsdl-org:mainfrom
ccawley2011:woodeneye-gamepad

Conversation

@ccawley2011

Copy link
Copy Markdown
Contributor

No description provided.

@slouken

slouken commented Oct 6, 2025

Copy link
Copy Markdown
Collaborator

This needs to be adjusted to match the SDL coding style.

@ccawley2011

Copy link
Copy Markdown
Contributor Author

This needs to be adjusted to match the SDL coding style.

Could you clarify what needs changing?

Comment thread examples/demo/02-woodeneye-008/woodeneye-008.c Outdated
@slouken slouken added this to the 3.x milestone Oct 9, 2025
Comment thread examples/demo/02-woodeneye-008/woodeneye-008.c Outdated
@expikr

expikr commented Oct 24, 2025

Copy link
Copy Markdown
Contributor

What I had in mind while writing the original example was to convey the following two messages to anyone reading the code:

  1. You’ve seen joystick splitscreen before, that’s nothing special. But did you know that Mouse+Keyboard can do local splitscreen too?
  2. Look how little code it takes to get something like this working!

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.

@slouken

slouken commented Oct 24, 2025

Copy link
Copy Markdown
Collaborator

That's fair feedback, and since @ccawley2011 seems to be away, I'll go ahead and close this for now.

@slouken slouken closed this Oct 24, 2025
@ccawley2011

Copy link
Copy Markdown
Contributor Author

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.

@slouken

slouken commented Oct 24, 2025

Copy link
Copy Markdown
Collaborator

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?

@slouken slouken reopened this Oct 24, 2025
@icculus

icculus commented Nov 8, 2025

Copy link
Copy Markdown
Collaborator

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. */

@expikr expikr Nov 8, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just get rid of dpad events entirely, use the left stick for analog movement instead.

}
}

static void updatePlayerGamepad(Player *player)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@expikr

expikr commented Nov 8, 2025

Copy link
Copy Markdown
Contributor

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.

@icculus

icculus commented Nov 8, 2025

Copy link
Copy Markdown
Collaborator

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. :)

@icculus

icculus commented Nov 19, 2025

Copy link
Copy Markdown
Collaborator

I have something sketched up in mind of a separate example that I think would work better as demonstration of how to utilize joysticks.

Oh, I just reread this...a separate example that does something better with joysticks is definitely welcome, but I'd like to get something into Woodeneye, for consoles that only have joystick input, even if it's not perfect.

If we can get this patch in a state that is less "shoehorned," let's still do that. I'm also okay with merging this as-is and then improving the approach from there in further commits.

@expikr

expikr commented Nov 23, 2025

Copy link
Copy Markdown
Contributor

Aside from the above suggestion to split off the movement vector to its own utility function that incorporates all input methods into its calculation, a question: are there any platforms that have only the right joystick without a left counterpart?

@icculus

icculus commented Nov 23, 2025

Copy link
Copy Markdown
Collaborator

The Sony PSP has the opposite problem: an analog left stick and no right stick. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants