N64: C buttons mapped to North/X or East/A sometimes do not register

[eomanis]

Description

I have mapped the N64 C buttons onto my gamepad like this:

It is very close to the N64 gamepad layout and works well with some games, such as Star Fox 64, where you routinely use C-Left and C-Down (for boost and brake), or, say, Super Smash Brothers for jumping.

Expected behavior

The buttons to work as they are mapped, i.e. pressing North/X should yield a C-Left and pressing East/A should yield a C-Down.

Actual behavior

Sometimes, pressing North/X or East/A do not register at all.

Holding the "Alternate C Buttons Mode" button is not involved.

The core's "Independent C Buttons Mapping" option is OFF, i.e. in default new-configuation state.

The C buttons on the right analog stick always work.

Here is a screen capture using Yuzu's settings display as gamepad input visualization:

https://github.com/libretro/RetroArch/assets/5933155/0dd90cc7-0861-4fae-b89c-3a3df9c2e471

Steps to reproduce the bug

1. Set up your gamepad and the core button mappings as described
2. Try to use North/X or East/A in a game
3. Notice the input of these buttons glitching

Bisect Results

(Not bisected)

Version/Commit

local/libretro-core-info 1.16.0.3-1 (libretro)
    Libretro core info files
local/libretro-parallel-n64 5243-1 (libretro)
    Nintendo 64 core
local/retroarch 1.16.0.3-1 (libretro)
    Reference frontend for the libretro API
local/retroarch-assets-ozone 1:481-1 (libretro)
    XMB menu assets for RetroArch
local/retroarch-assets-xmb 1:481-1 (libretro)
    XMB menu assets for RetroArch

Environment information

• OS: Arch Linux
• Compiler: Distribution native packages

[eomanis]

I have found that setting the core's "Independent C Buttons Mapping" to ON can work around the bug.

The important things to make it work are:

• After toggling the option from OFF to ON you need to close and re-open RetroArch, otherwise it will not be effective.
• All your core-specific button mappings will be borked and have to be re-assigned. In particular the shoulder buttons / shoulder triggers will have wrong assignments.
• Now, instead of e.g. "C Buttons Y +" you assign "C-Down" to East/A.

[sonninnos]

You are supposed to use the independent c-buttons option for that usage.

[eomanis]

You are supposed to use the independent c-buttons option for that usage.

True, as I have found out.

I still consider the bug valid though, until someone can point out to me a good reason why buttons working sometimes is intended behavior.

In particular, as can be seen in the video, when a North/X or East/A button press fails, there is no conflicting input from the right analog pad.

A reasonable expectation would be the right analog pad taking precedence if it has a conflicting input because its axis tilt is actually large enough to trigger a C button input, e.g. over the 50% threshold, which is not the case in the video.

If right analog pad deadzone jitter prevents North/X or East/A button inputs, then it is a bug.

Plus, and I consider this important, it is a poor and confusing onboarding experience for users.

[sonninnos]

Valid sure perhaps, but it is a core issue and not RetroArch issue.

[hizzlekizzle]

So, is that what's actually happening? the analog deadzone is causing buttons with the same assignment to not fire?

[eomanis]

So, is that what's actually happening? the analog deadzone is causing buttons with the same assignment to not fire?

Maybe, it is so far an unfounded hypothesis. I could not come up with another sensible explanation so far.

[eomanis]

Valid sure perhaps, but it is a core issue and not RetroArch issue.

Probably. I assume deadzones and trigger thresholds are handled by ParaLLEl N64 itself, i.e. the core gets the raw inputs from RetroArch, because there are core-specific analog deadzone and range settings.

There is the possibility of changing the default state of the "Independent C Buttons" setting to ON for a more out-of-the-box user experience. Still, that is making assumptions about what settings the majority of users use.

[hizzlekizzle]

it does indeed get the raw inputs from the frontend, but how it handles those is up to the core. Since this isn't an all-cores-have-it problem, the culprit is probably in the core's input handling.

I'm under the impression that the default mapping is preferred for modern gamepads, while the independent c-button mode is preferred for original N64 pads and other 6-face-button pads.

[eomanis]

I'm under the impression that the default mapping is preferred for modern gamepads, while the independent c-button mode is preferred for original N64 pads and other 6-face-button pads.

The thing is, even after switching on "Independent C Buttons" one can still easily map the C buttons onto the right analog stick of a modern gamepad, as shown in the initial post's picture.

I.e., as far as I can tell, enabling "Independent C Buttons" does not come with any sacrifice or drawback.

To put it another way, I cannot come up with a situation where having "Independent C Buttons" disabled would make something possible that would not be possible otherwise. Having this setting seems like having additional complexity for no gain at all.

So why isn't it always-on? There seems to be no use case for having it disabled. Anyone have an actual counterexample for this assessment?

[hizzlekizzle]

Sure. Enabling it gets rid of the alternate c-button mode, which lets you hold R2 to move the c-buttons up from the analog stick to the face buttons. This behavior takes some getting used to, but once one becomes accustomed to it, it's very nice (IIRC, it's based on the Classic Controller mapping Nintendo used for N64 Virtual Console games on the Wii).

[eomanis]

Enabling it gets rid of the alternate c-button mode

Oh right, it does that. Point taken.

[albrechtjess]

So, is that what's actually happening? the analog deadzone is causing buttons with the same assignment to not fire?

Maybe, it is so far an unfounded hypothesis. I could not come up with another sensible explanation so far.

Un-binding the right stick entirely fixed this for me so I think it's likely.