Mapping controls for individual cores

RetroArch General
#1

I’ve just extracted the Windows Megapack, set up a controller, added some BIOS, etc., and everything is working. However, I must be missing something. I’m using the genplus_gx core and, while my general (retropad autoconfig) controls work, they’re not mapped out properly to emulate a Genesis controller as the autoconfig is largely based on the modern PS2-style layout and I am using a Saturn USB pad with an ABC/XYZ layout. I could guess-and-test until I have a config for use only with this core that happens to map correctly, but this seems inefficient and I would have to test in a 6-button Genesis game where I can verify that C is truly mapped to C and Y to Y, etc… There must be another way.

How can I generate configs for each particular core without spending a lot of time trial-and-erroring what retropad config will just happen to work for each core?

I see no options in the genplus_gx core for mapping individual buttons which leads me to believe there is a maximum of one “layer” of mapping, so to say (meaning I can’t have a general retropad config that maps to a separate per-core config). How then can I map the C or Z button, or the Mode button which genplus_gx (and the Genesis itself) utilizes when the retropad config doesn’t have these buttons?

Edit: From about a year ago:

Well, we just bind Genesis Plus GX controls to the following ‘buttons’ -

static struct bind_conv binds[] = { { RETRO_DEVICE_ID_JOYPAD_B, INPUT_B }, { RETRO_DEVICE_ID_JOYPAD_A, INPUT_C }, { RETRO_DEVICE_ID_JOYPAD_X, INPUT_Y }, { RETRO_DEVICE_ID_JOYPAD_Y, INPUT_A }, { RETRO_DEVICE_ID_JOYPAD_START, INPUT_START }, { RETRO_DEVICE_ID_JOYPAD_L, INPUT_X }, { RETRO_DEVICE_ID_JOYPAD_R, INPUT_Z }, { RETRO_DEVICE_ID_JOYPAD_UP, INPUT_UP }, { RETRO_DEVICE_ID_JOYPAD_DOWN, INPUT_DOWN }, { RETRO_DEVICE_ID_JOYPAD_LEFT, INPUT_LEFT }, { RETRO_DEVICE_ID_JOYPAD_RIGHT, INPUT_RIGHT }, { RETRO_DEVICE_ID_JOYPAD_SELECT, INPUT_MODE }, };

What you could try is remapping the controls in Settings so that the buttons correspond correctly.

Anyway, I’ll introduce emulator-specific button labels in a next release - so that it becomes easier to map them.

Is this where we’re still at today? Having this map is good enough for me, but the fact that I found it in a post at GBAtemp and not in any documentation seems odd as I consider this completely vital information to having a proper configuration for genplus_gx. Without this, it’s a guessing game.

#2

It’s a bit of a pain initially to figure it out, but the way you can use multiple configs and the fact that you can remap every system key makes RetroArch’s input mapping system pretty powerful. You can create configs per core or per game and have a separate frontend feed it the command line to always load a specific config for a certain system or game. Now you can use the built in GUI to swap between configs as well.

It’d be nice to have an easy to use graphical interface for remapping for new users not used to editing cfg files or using the command line.

#3

It’s definitely powerful and I do appreciate that. Any all-encompassing front-end (though RetroArch is a bit more than that) really needs that flexibility to satisfy the most demanding users. Like I said, now that I found the control map for this particular core on GBAtemp it isn’t a problem. The issue is really accessibility and some sort of mapping in the GUI on a core-to-core basis would be quite nice to assuage that and decrease the upfront cost of admission, so to say.

#4

Retroarch is a reference implementation of libretro. My understanding is that better UI will come eventually.

#5

I confirm

#6

There are plans for a MAME OSD-style button mapping function accessible via RGUI, though it may take a bit of time to get that implemented. Even then, I’m not sure if the plan is to have core-specific binding names (like A/B/C/X/Y/Z in this case) or stick with a single retro_pad binding interface, which would still be a guessing game but at least relatively convenient to trial-and-error.

The key you found on GBAtemp is taken from the genplusgx source code, specifically libretro.c. You can find the same information for any core by looking in that core’s libretro.c file. Not the most convenient form of documentation, but it is there if you know where to look.

#7

Ahh, that will be very useful as I configure additional cores.