Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Patch] Do not swap B/X buttons on GameCube controller unless it's requested #3497

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2019-12-31 04:02:17 +0000, Ethan Lee wrote:

Created attachment 4144
Revert button label commit, use hint instead

Basically replicating the solution of the Switch Controller's button label issue. Physical layout should take priority unless it's explicitly requested by the user or application!

On 2019-12-31 07:35:25 +0000, Sam Lantinga wrote:

Actually, the Switch Controller code has a special case to ignore the hint if the controller uses the GameCube form factor. Basically the (B) button on the GameCube controller is always assumed to be the B button since it has such a unique physical layout, and everything falls out from there.

On 2019-12-31 07:36:56 +0000, Sam Lantinga wrote:

Also, if respecting the hint were desirable, then it would also need to be taken into account in the Mayflash adapter controller binding, in SDL_gamecontrollerdb.h

On 2019-12-31 08:04:28 +0000, Ethan Lee wrote:

Since the hint defaults to true anyway, I wonder if fixing it in the Switch path is worthwhile as well. I’m not sure how the Mayflash path would be fixed, but the main concern is the top/left/right/bottom position - the shapes are definitely weird but for games that might only care about location and not shape (some XNA games for example) it can get really disorienting, particularly if a developer ends up writing a fixed path for menu action sets exclusively (i.e. only swap A/B in menus).

Point being, I need a hint to turn this swap off, this hint’s name suggested it would be an appropriate fix.

On 2019-12-31 08:51:41 +0000, Sam Lantinga wrote:

Yeah, I'm debating whether to make the hint apply here. I think it sort of makes sense, if you presume a game knows about the GameCube layout and actually wants to swap buttons. Maybe we should use a GameCube specific hint?

What's the use case where an XNA game cares about location and not shape?

On 2019-12-31 16:56:24 +0000, Ethan Lee wrote:

To name a few:

  • Before the Echo explicitly maps the diamond buttons to directions, so without an option to turn this off, left and right are permanently swapped.
  • Dust: An Elysian Tail, Dishwasher: Vampire Smile, Charlie Murder, and Salt & Sanctuary expect the left and top buttons to be primary attack buttons, while the right button is an extra attack button. With the swap forced, the more important attack button is moved to one of the outer buttons. Additionally, Dust already has separate action sets for menus and physical layout, so inserting GameCube behavior for the joystick GUID is trivial (FNA encourages querying vendor/product information through an extension).
  • Flinthook and RetroArch specifically have toggles for Eastern/Western menu button options, adding an extra layer of confusion for GameCube users who just want to assume more common layouts and rebind to what they're already used to rebinding.

I'll happily take a second environment variable, whatever will guarantee that this patch will make it into revision control.

On 2020-03-10 21:24:41 +0000, Ethan Lee wrote:

Argh, forgot about this because my search didn't include RESPONDED statuses.

This is still a pretty major breakage for FNA, but worst case I can revert this change in the fnalibs builds. But, that'd be a pretty microscopic undocumented change from upstream that pretty much nobody but us would know about.

I'm still up for both using the existing USE_BUTTON_LABELS variable as well as making a new variable for GameCube, whichever has a better chance of making it into 2.0.12 at the last minute (and of course, I can test whatever is chosen).

On 2020-03-10 23:52:20 +0000, Sam Lantinga wrote:

So I committed this:
https://hg.libsdl.org/SDL/rev/e6a2558ec791
but I think we'll need to modify it, because I don't think it matches the behavior of the Nintendo Switch GameCube form factor controllers. On those, both A and B and X and Y are swapped, but you're leaving Y alone and only swapping X and B.

I think that's the correct positional mapping, but I'll need to test those, so I'm going to back out your patch for 2.0.12 release.

On 2020-03-11 00:13:25 +0000, Ethan Lee wrote:

The Switch GameCube controllers I believe show up as Switch Pro, so the mappings there will be different. Testing latest tip now to verify both swap modes.

On 2020-03-11 00:20:15 +0000, Ethan Lee wrote:

Tested both modes, this patch should work! AFAIK the Switch GameCube controllers are a whole separate thing for SDL_hidapi_switch.c.

On 2020-03-11 00:38:20 +0000, Sam Lantinga wrote:

Okay, I made the hint work consistently for both the GameCube driver and Nintendo Switch controllers that have GameCube form factor:
https://hg.libsdl.org/SDL/rev/78d0bb6f3b8f

I'm leaving this open so we can address the Mayflash adapters after 2.0.12 ships.

On 2020-03-13 22:09:31 +0000, Sam Lantinga wrote:

This is now fixed for the Mayflash adapters as well:
https://hg.libsdl.org/SDL/rev/2ef60abd9132

On 2020-03-13 23:55:02 +0000, Ethan Lee wrote:

Now that the gamecontroller mappings use the label hint directly in their bindings, do we need to remove the remap code from the GameCube driver to prevent double flipping?

On 2020-03-14 02:05:26 +0000, Sam Lantinga wrote:

No, the GameCube driver doesn't handle the mayflash adapter. They're distinct driver paths.

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

No branches or pull requests

1 participant