N64 button mapping woes

[lmp03]

Read this page in the docs, under the controls heading. It shows how the controller is mapped and what files to edit to change the mapping

[andharri]

Hi,

Thanks for the reply. Looking at the link it seems like I have edited all the requisite files. In fact I believe I have assigned "A" to be button(6) in the following files yet still it is not taking:

• InputAutoCfg.ini
• mupen64plus.cfg
• es_input.cfg
• 'DragonRise Inc. Generic USB Joystick .cfg'

Is there anything else I am missing?

[lmp03]

This post is deleted!

[lmp03]

@andharri
The emulator you are using is not part of RetroArch and so the buttons are mapped differently. If you map the “b” button to the button you want to be “a” and the “y” button to the button you want to be “b” it should work properly

[ColoQ]

I came here to ask this exact question with the exact same config and a joystick from Amazon that identifies the exact same way. The only slight difference I see is that I built from a retropie image .iso downloaded from the Retropie.org.uk site.

The response that the mupen64 is not the RetroArch emulator doesn't make sense... as well thats the default per the wiki.

I even purchased and tried another USB N64 style controller and still get the same behavior with that.

I've even SSHd into the pi, ran jstest while running the game and verified that jstest is seeing me press the correct button (A on the physical controller, Button 6 in the mapping provided by jstest) and that mupen64 is still not responding correctly.

At this point it appears to be a bug (multiple people, same version) common to new versions?

[ColoQ]

@coloq
... the relevent changes to my /opt/retropie/configs/n64/retroarch.cfg gile are below.. and it still doesn't work.

input_player1_b = "z"
input_player1_b_btn = "8"
input_player1_b_axis = "nul"
input_player1_b_mbtn = "nul"
...
input_player1_a = "x"
input_player1_a_btn = "6"
input_player1_a_axis = "nul"
input_player1_a_mbtn = "nul"

[lmp03]

@coloq
It is not a bug
First, read this doc page under The RetroPad concept heading. This explains the way that the controller is mapped in RetroArch. Since the mupen64plus is not RetroArch that virtual “RetroPad” is different. So when you first configure your controller and tell it which button is “a” or “b” or something else, RetroArch handles that input one way by mapping certain buttons a certain way. mupen64plus is not part of RetroArch and so it handles the input from the “configure input” screen differently than RetroArch does.

[ColoQ]

@lmp03
Your input is neither helpful or correct.

Per https://github.com/RetroPie/RetroPie-Setup/wiki/Nintendo-64
there is this specific line
"While the lr-mupen64plus core has the convenience of RetroArch configurations and directly reading zip compressed files, the actual Mupen64plus does better with performance."
The wiki there also states I can modify the retroarch.cfg file to modify button mappings for lr-mupen64plus.

But if that is not enough. I have also modified the /opt/retropie/configs/n64/mupen64plus.cfg, and switched the core that loads my ROM to straight mupen64, and seen no effect. (relevant output below)

Start = "button(9)"
Z Trig = "button(7)"
B Button = "button(8)"
A Button = "button(6)"
C Button R = "button(1)"
C Button L = "button(3)"
C Button D = "button(2)"
C Button U = "button(0)"

So... ... still having the issue despite what documentation says I should do...

[dankcushions]

@coloq lr-mupen64plus is not the default n64 core, mupen64plus is. they are two seperate emulators - the 'lr-' prefix indicates a libretro/retroarch core.

mupen64plus does not use retroarch.cfg, BUT the cfg file it DOES use is populated during retropie's initial install, so you shouldn't need to edit it if you bound your pad in a sensible way.

that said, if you do, it's the mupen64plus.ini file you need to edit. the cfg file is mostly automatically overwritten from that, i believe.

[lmp03]

@coloq said in N64 button mapping woes:

So... ... still having the issue despite what documentation says I should do...

As I mentioned before, if you map the physical “a” button to the virtual “b” button and the physical “b” button to the virtual “y” button it will work as you want.