Joyconfig per core configuration

I use a per-core setup on Windows. The issue is I can’t figure out how to automatically switch joypad configurations based on currently active core configuration. For the NES/SNES and Genesis, I use a Saturn USB pad. The Genesis and Nintendo cores require very different joyconfigs. I need to be able to specify which to use for each core. When I have like-named joyconfigs to correspond to each core in the autoconfig directory, it doesn’t matter as the Genesis configuration (perhaps by alphabetical precedence) is always selected regardless of active core. If I remove it, then the NES joyconfig is always active.

I need to be able to explicitly choose which joyconfig should be active for each core, but I cannot find a parameter that will allow me to do that in my per-core configs. This is a very simple matter, and surely I am missing something… I’m on a Win64 build from a few nights ago.

After embedding my different gamepad bindings for different consoles in various per-core retroarch.cfgs, I’ve concluded at this point it seems maintaining separate instances of RetroArch is a better idea. Maybe someday a unified setup will be practical for people who want to use vastly different bindings (and sometimes different controllers) depending on the core, but I’ve encountered far too many issues, the last of which was d-pad bindings inexplicably not working in retroarch.cfg, mandating the use of autoconfig bindings which I’ve found to be paradoxically inflexible.

Yeah, obviously not optimal but perhaps the path of least resistance at the moment.

Autoconfig and per-core configs are probably used by opposite ends of the userbase. Autoconfig just works and it’s good for new users. Anyway, not saying per-core configs are perfect. I actually got frustrated too! and I use the appendconfig option most of the time. I only use one pad though so I guess you might experience problems that most users don’t.

I swear I’ll try per core configs this weekend and try to address these in the pad configuration guide I’ve been writing (it seems to be the most complicated aspect of using RA)

http://blog.andressm.org/retroarch-game … iguration/

After starting this thread, I moved to using controls embedded in my retroarch.cfgs and disabled autoconfig, but the d-pad only worked when using an autoconfig key map. Thanks to your very helpful guide I saw this: “You shouldn’t have a RetroPad button/axis mapped to more that on gamepad button/axis since that’s not supported.” If that also applies to the keyboard, then my binds were failing because I also had the d-pad mapped to arrow keys for the sake of navigating menus with my keyboard or dedicated media controller when not using my gaming pad. The auto-population of all possible binding variables in retroarch.cfg makes double-binding quite tempting for someone who doesn’t realize it’s prohibited (it’s also a mess of unused nul lines which make editor navigation a bit annoying :P).

Thanks for that–not at the PC to test yet but I should be able to move back to a unified setup. Now to figure out how to prevent my startup config from adopting a core-specific config’s dsp settings upon exit despite the general config not being save-upon-exit…

Edit: If I may, I think a retropad map of the Genesis controller would be useful alongside the NES/SNES/N64/PS1 maps in your guide. It having no select and rows of three face buttons make the controls for it a little less intuitive.

I will add the genesis yeah! Actually I don’t think there is a problem with binding to KB and controller at the same time but I could be wrong. What RA really dislikes in my experience is having the same binding twice

say input_player1_start_button more than one time is a no no.

I use notepadd++ and textfx sort alphabetically to debug this kind of stuff but yeah I had these issues once.

I have no problem with the d-pad being mapped to my keyboard arrow keys and controller d-pad at the same time. Face buttons and shoulders are fine too.

You’re right that both KB and button/axis bindings are allowed simultaneously. I’ve tried binding the d-pad again so that I can get on with per-core configs like I wanted. However I’m still stumped as to why, with input_autodetect_enable = “false”, I can bind the d-pad in RGUI or manually and the d-pad will work fine in-game but not for navigating the RGUI menu. It works perfectly when using an autoconfig.cfg. This makes absolutely no sense to me. I’ve tried in both a June and July Win64 build.

Here’s the fully-working autoconfig file:

input_device = "USB Gamepad"
input_driver = "dinput"
input_b_btn = "1"
input_y_btn = "0"
input_start_btn = "8"
input_select_btn = "5"
input_up_axis = "-1"
input_down_axis = "+1"
input_left_axis = "-0"
input_right_axis = "+0"
input_a_btn = "2"
input_menu_toggle_btn = "6"

And here’s the retroarch.cfg bindings:

input_driver = "dinput"
input_device_p1 = "0"
input_player1_joypad_index = "1"
input_libretro_device_p1 = "1"
input_player1_analog_dpad_mode = "0"
...
input_player1_b = "z"
input_player1_b_btn = "1"
input_player1_b_axis = "nul"
input_player1_y = "a"
input_player1_y_btn = "0"
input_player1_y_axis = "nul"
input_player1_start = "enter"
input_player1_start_btn = "8"
input_player1_start_axis = "nul"
input_player1_select = "rshift"
input_player1_select_btn = "5"
input_player1_select_axis = "nul"
input_player1_up = "up"
input_player1_up_btn = "nul"
input_player1_up_axis = "-1"
input_player1_down = "down"
input_player1_down_btn = "nul"
input_player1_down_axis = "+1"
input_player1_left = "left"
input_player1_left_btn = "nul"
input_player1_left_axis = "-0"
input_player1_right = "right"
input_player1_right_btn = "nul"
input_player1_right_axis = "+0"
input_player1_a = "x"
input_player1_a_btn = "2"
input_player1_a_axis = "nul"

First works in RGUI and in-game, second works in RGUI except for axis assignments but they work perfectly in-game. input_player1_joypad_index = “1” is correct. What could the difference possibly be?

I don’t really care about per-core configuration anymore as I’m getting by fine with my separate retroarch setups, but I’d like to figure out why my retroarch.cfg d-pad bindings aren’t working in RGUI despite them working in-game in case there might be a bug, however unlikely it is that I would be the one to come across it.

It seems like if my configuration is the same at startup as when I load a core and ROM (input_autodetect_enable = “false”) then a RetroPad d-pad that works in-game should also work in RGUI. I’m even able to bind the D-pad inside RGUI’s input configuration options. I can’t reconcile it, particularly when the other buttons on the controller (generic USB HID) work just fine in RGUI. My working theory is it’s the difference between ‘input_up_axis = “-1”’ format in autoconfig files versus ‘input_player1_up_axis = “-1”’ in retroarch.cfg, as if RGUI looks only for the former and the core is perfectly able to find the latter (with _player1 in the variable name). If that’s true, then RGUI correctly looks for “input_player1_up” as my keyboard bindings work just fine both in-game and in RGUI.

Andres, I feel bad about asking you to look into the configs I posted above after seeing all the abuse you’ve taken and time that’s been lost attempting to help the… mildly unpleasant Dogway in the other thread, but does anything appear to explain why retroarch.cfg d-pad bindings aren’t working in RGUI but work in-game? Your time is appreciated.

Edit: Now on 7/27 build.

Do I know you dude? What I know is that I’m definitely not going to ever look into your problem.

That’s okay. I understand you have enough of your own problems to look into. Best of luck.

It’s an odd behavior indeed I’ll look at it along with per-core stuff this weekend

You need luck. I work my luck mate, keep it trolling, you are walking the wrong path.

Added Genplus GX

Same settings with input_autodetect_enable = “false” work perfectly in RetroArch-20140105-Win64-MegaPack. I can only conclude it’s an RGUI bug introduced sometime between 1.0.0.0 and July when I first encountered it. The problem has been present in all three July win64 builds I’ve used.

To reiterate:

When input_autodetect_enable = “false”, all button assignments EXCEPT axis assignments (D-pad of a number of controllers I’ve tried) work in RGUI, and all button assignments INCLUDING axis assignments work in-game. Axis assignments only work in RGUI if input_autodetect_enable = “true”. This requires keyboard or joy2key/xpadder navigation of menus.

I don’t have issues with manual binding of pads. I have autodetect disabled and I can navigate RGUI use both dpad and axes in games. Whose build are you using?

Let me try with a clear config

I’ve been using these: https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd

I can’t tell you how many times I’ve started with fresh installs and default configs at this point. There most be something up with this particular series of builds… I’ll set up my own environment to build when I get a chance.

Edit: Based on your guide you’re probably using xinput. If so, you might test with dinput to mimic my setup.

Ok here are my findings with autodetect ENABLED and an XBOX 360 controller:

  • In game, everything works but analogs, analogs requre analog d-pad emulation
  • RGUI, everything works but analogs, analogs requre analog d-pad emulation

This is the desired behavior for this pad. And is correct

With input_autodetect DISABLED

  • In game, everything works but analogs, analogs requre analog d-pad emulation
  • RGUI, everything works but including analogs, without d-pad emulation, this is incorrect and shouldn’t happen

So there is a difference yeah but what’s wrong is being able to use analogs to navigate RGUI without dpad emulation enabled, that’s inconsistent with the input model.

So you’re saying that with input_autodetect disabled, your X360 d-pad and analogs both work in RGUI? If only your analogs worked and with d-pad emulation disabled, then I would think “Okay, so only analog sticks work in RGUI, which is why my stick-less controller’s d-pad isn’t working in RGUI but works in-game.” If your analogs AND d-pad work in RGUI with d-pad emulation disabled, then I’m not sure what that says of the problem I’m experiencing, but I’m hesitant to discount what seems like an obvious connection.

To put it briefly, it would seem that analogs working in RGUI without d-pad emulation is related to my actual d-pad not working in RGUI.

I went to make a bug report at the Git, but it seems you’ve done it for me. Thanks! I followed up with a concise description of my experiences from this thread.

Yes, when it’s disabled both analog and d-pad are working to navigate RGUI.