Unique config/controller mapping per Gamepad per Core
-
Hi, have tried to figure this one out for a couple of weeks now going through the significant number of posts that have been here before but don't quite seem to address what I'm looking for to resolve my specific issue.
What I'm looking for:
I have 2 8bitDo controllers that function fine with my RetroPie setup, an SF30 Pro and M30.The SF30 Pro is pretty straight forward with autoconfig mapping and generally works sensibly in most cores.
The M30 however I'd like to generate unique button mappings on a per core basis but only specific to the the M30.
In Emulation station I have the buttons mapped to their face values (so A is the A button on the M30, X is X etc)
What I've tried and issues I'm having:
First thing I tried was using the core remapping functionality in retroarch as suggested here. Using gameboy as an example I'd go into retroarch, swap A and B around (since they're physically the wrong way around on the M30 for a Gameboy) and then save that remap for the core. That produces the gambatte.rmp file and works fine for the m30 when I go into a game.However, if I reboot and start up with my SF30 Pro instead then head into a gameboy game the A and B buttons are swapped around for that controller. So it would seem the retroarch remapping functionality is specific to the core but not specific to the gamepad? Perhaps it's specific to the player, but that doesn't help either since either the SF30 Pro or M30 could be player 1 on any given day - Is this the intended behaviour of Core input remapping?
Next up I tried manually adding the autoconfig data for the M30 into the retroarch.cfg of a specific core (again gameboy for testing) - adding the autoconfig lines for the M30 and swapping around the values for A and B here above the #include as suggested seems to do nothing.
I then stumbled across a reddit post that mentioned I could add
joypad_autoconfig_dir =
to overdid ether autoconfigs that are loaded with the core. Made a joypad directory in the core directory added a copy of the M30 autoconfig file, swapping the A and B button values around, and while it seems to suggest it's been loaded when loading the core there didn't seem to be any change in button mapping behaviour. This method also presents an issue as it seems to entirely ignore the default autoconfig directory for the core with the override - so the SF30 Pro auto config would need to be added to each core with this change even though it's not being altered.I realise the Gameboy test is a bit artificial (I could just map the button bindings to work "better" in emulation stations - but there are other cores like N64 were I see this being a proper issue if I want to use either controller from time to time)
Some information about my setup:
- Retropie 4.6.1
- Raspberry Pi 4 (overclocked to 1.95GHz, stable for some weeks)
- 8BitDo controllers connected via Bluetooth
- System is part of a Picade setup so it has an xHat for arcade inputs as well (maps like a keyboard)
Any help here would be much appreciated.
-
@Hobsie said in Unique config/controller mapping per Gamepad per Core:
. So it would seem the retroarch remapping functionality is specific to the core but not specific to the gamepad? Perhaps it's specific to the player, but that doesn't help either since either the SF30 Pro or M30 could be player 1 on any given day - Is this the intended behaviour of Core input remapping?
Yes, that's how it works.
Made a joypad directory in the core directory added a copy of the M30 autoconfig file, swapping the A and B button values around, and while it seems to suggest it's been loaded when loading the core there didn't seem to be any change in button mapping behaviour.
Make sure you're not loading any other
.rmp
or configuration override files. This should work with your specific use case. -
Thanks for the assist @mitu - I just went back and cleaned things up and you're right the method of using
joypad_autoconfig_dir = "/opt/retropie/configs/gb/joypad/"
and adding a modified autoconfig for the M30 in there seems to work (as you suspected it looks like I had a lingering.rmp
file that caused an issue at the time)So this works now, but I'm seeing an issue moving forward. I just tried load up with the SF30 Pro as player 1 and when I loaded the GB core it notified me that it wasn't configured. So it would seem using
joypad_autoconfig_dir =
completely overrides the directory used for autoconfigs and not just provide a means to override individual configs.Copying the SF30 Pro auto config to that directory allows it to work again, but that's a lot of manual setup if I do this for multiple cores, not to mention if I add new types of gamepad in the future! Doesn't look like
joypad_autoconfig_dir =
recurses directories either so I don't think I can just do something like symlink the original and provide an override in the parent directory.Any thoughts on improving the setup/process here? Ideally I'd just add the modified config for the M30 as an override in the core config but use the global one's for the rest.
-
If you're thinking of doing this for multiple joysticks/systems, then it might be easier to use an
onstart
script forruncommand
. Instead of overridingjoypad_autoconfig_dir
, keep a list of desired configurations for a joystick and just copy it over tojoypad_autoconfig_dir
before the game starts. This way you'll keep one config per standard controller (like the SF 30 Pro) and you can have configs per-system for certain controllers.Supposing you have all your possible
.cfg
for you controller /home/pi/configs/m30/, an on-start script like would look like:joypad_config_dir="/opt/retropie/configs/all/retroarch-joypads" if [[ "$2" == "megadrive" ]]; then cp -f /home/pi/configs/m30/m30-config-for-md.cfg "$joypad_config_dir/8BitDo M30 gamepad.cfg" elif [[ "$2" == "snes" || "$2" == "psx" ]]; then cp -f /home/pi/configs/m30/m30-config-for-snes-and-psx.cfg "$joy_config_dir/8BitDo M30 gamepad.cfg" else # Standard config for all other systems. cp -f /home/pi/configs/m30/m30-config-standard.cfg "$joy_config_dir/8BitDo M30 gamepad.cfg" fi
Somehow this comes up as more complicated than it is and I can't help of thinking if there's a better way.
-
Thanks again @mitu that's sounds like a workable solution. I've dabbled with retropie a bunch of times over the last few years but never looked under the hood - really good to find out about
runcommand-onstart.sh
that adds a lot more flexibility.Having said that, totally agree - this seems like quite a customised solution for a situation that can't be too uncommon when we're talking about supporting many different controller types across many different platform cores and no guarantee of what player is using what gamepad.
Having something like a
joypad_autoconfig_override_dir =
that could look at custom configs and override existing ones would help. Having retroarch be capable of storing button mappings knowing which gamepad they're for and not just just player1 or 2 etc. would help more.Thanks again though, you've given me enough to write my own script for this and taught me about some of the more advanced features I'd have struggled to stumble across myself.
-
Wow, thank you both - it took me so long to find this - the joypad_autoconfig_dir option is almost like a secret! (OK, at least one other person knows).
I have a mix of controllers with 4 or 6 "face buttons", and I have Sega Mega Drive, SNES and Arcade ROMs set up in RetroPie. Even if I only had one type of 6 button controller I think that using separate autoconfiguration files to define the gamepad binding to RetroPad for different cores would be easiest. When there are a mix of controllers that might (or might not be) connected to the RetroPie box hardcoded configuration breaks down, core input remapping is not suitable, and the ideas here are the only way I've found that just work.
For example, with separate autoconfiguration folders, in my /opt/retropie/configs/arcade/ directory I have
pi@rpi-tv:/opt/retropie/configs/arcade $ cat retroarch.cfg # Settings made here will only override settings in the global retroarch.cfg if placed above the #include line input_remapping_directory = "/opt/retropie/configs/arcade/" joypad_autoconfig_dir = "/opt/retropi/configs/arcade/joypads" #include "/opt/retropie/configs/all/retroarch.cfg"
I created the new directory joypads and copied all of the .cfg files from /opt/retropie/configs/all/retroarch/autoconfigs in to it, so that it looks like this:
pi@rpi-tv:/opt/retropie/configs/arcade $ ls -1 joypads/ 'Microsoft X-Box One pad.cfg' 'SWITCH CO.,LTD. USB Gamepad .cfg' 'USB gamepad .cfg'
Finally I edited the "SWITCH CO.,LTD. USB Gamepad .cfg" file in a text editor two swap the assignments that I wanted for the arcade ROMs. (It's a bit confusing that there are fba, FinalBurn Neo and Mame-2003 config folders too, I suppose I must duplicate or symlink them?
Similar routine for the Genesis/Mega Drive core.
I'm happy it's working, but obviously it would be nice to avoid having duplicate copies of the configurations that don't change. Also, as you've said, if I ever add a new controller to the mix, I would have to copy that everywhere too, but I don't expect to do that.
-
@mitu said in Unique config/controller mapping per Gamepad per Core:
If you're thinking of doing this for multiple joysticks/systems, then it might be easier to use an
onstart
script forruncommand
. Instead of overridingjoypad_autoconfig_dir
, keep a list of desired configurations for a joystick and just copy it over tojoypad_autoconfig_dir
before the game starts. This way you'll keep one config per standard controller (like the SF 30 Pro) and you can have configs per-system for certain controllers.
...
Somehow this comes up as more complicated than it is and I can't help of thinking if there's a better way.I modified your script so that it doesn't need to know the names of my controllers or use any new folders:
joypad_autoconfig_dir="/opt/retropie/configs/all/retroarch-joypads" # Put this script in /opt/retropie/configs/all/runcommand-onstart.sh # To support different gamepad autoconfigurations for a joypad in different # libretro emulators copy the current .cfg and rename it with _default added # to the end of the filename. # For each gamepad+emulator combination that requires a variation create # a new copy of the .cfg_default file, changing "default" to match the libretro # core that it applies to, for example .cfg_lr-picodrive. # Modify each variation as needed. This script will copy the variations # (or the default) over the orginal .cfg file as required each time an # emulator is started. # Log output goes to /dev/shm/runcommand.log echo "$0: looking for custom gamepad autoconfigs for $2 in $joypad_autoconfig_dir" >&2 for default_cfg in $joypad_autoconfig_dir/*.cfg_default; do [ -e "$default_cfg" ] || continue # stop now if there are no matches target_cfg_name=${default_cfg%.*} # remove file extention .cfg_default required_variation_cfg="$target_cfg_name.cfg_$2" if [ -e "$required_variation_cfg" ]; then echo "Using autoconfig variation $required_variation_cfg" >&2 cp -f "$required_variation_cfg" "$target_cfg_name.cfg" else echo "Using default gamepad autoconfig $default_cfg" >&2 cp -f "$default_cfg" "$target_cfg_name.cfg" fi done
All of the .cfg variations stay together in the /opt/retropie/configs/all/retroarch/autoconfigs directory, but with different extensions to indicate which core they are needed for. For example, autoconfigs has these files:
pi@rpi-tv:/opt/retropie/configs/all/retroarch $ ls -1 autoconfig/ 'Microsoft X-Box One pad.cfg' 'SWITCH CO.,LTD. USB Gamepad .cfg' 'SWITCH CO.,LTD. USB Gamepad .cfg_default' 'SWITCH CO.,LTD. USB Gamepad .cfg_lr-fbneo' 'SWITCH CO.,LTD. USB Gamepad .cfg_lr-genesis-plus-gx' 'SWITCH CO.,LTD. USB Gamepad .cfg_lr-picodrive' 'USB gamepad .cfg'
The .cfg_lr-picodrive is a symlink to the .cfg_lr-genesis-plus-gx that I made just to check if it would work.
I put some logging in to remind me what's happening if I forget that it's there.
Using joypad_autoconfig_dir in retroarch.cfg seems a bit more "standard", to me so I've stuck with that here. I thought the script could be useful to share though :)
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.