Xbox Controller A & B buttons switched when playing? (Using Emulation Station)

Hey there so far I am loving Retroarch but there is one thing that is annoying me. I am using a program called emulation station as my front end when loading games and for some reason when I load a game using a Retroarch emulator and my Xbox 360 controller the A And B buttons are switched. For example I load up emulation station and select a game and load it. As soon as it loads the A button is the B function and the B button is the A function. Any idea how to configure it not to do this? I’ve also made a post on the Emulation Station forums: http://emulationstation.org/forum/index.php?topic=772.0

Reversed in the GUI when comparing EmulationStation and RA? It’s just that the behavior is different between them, basically a different convention

[QUOTE=Radius;21721]Reversed in the GUI when comparing EmulationStation and RA? It’s just that the behavior is different between them, basically a different convention[/QUOTE]

Ahh I figured it out. Yeah some of the buttons are reversed but I went into Retroarch’s options and was able to change it under input options. All is good now!

But that would reverse emulated console inputs too… Anyway if it works for you…

This actually made me think of something. Wouldn’t an ultimately better - if more involved and possibly convoluted - solution be to have separate control configurations between GUI and emulation?

Well nope… it would be a big change but I could make it possible to map the actions to different buttons, I was just talking to Twinaphex about this, I could do it like this:

OK - Retropad A Cancel - Retropad B Search - Retropad X Test - Retropad Y

Then you could change those like in the core remapping options. It will still use retropad but the buttons for the actions would be configurable.

Interesting. Assuming there aren’t any actions you can do via button/key commands that are possible both while in and out of GUI (I’m pretty sure there aren’t any), that seems like it would work just fine!

You’d need to have some sort of defaults for them to start with in that case, but that shouldn’t be a problem.

I already added this, but I don’t know enough about the underlying menu system to finish the GUI side, it hasn’t been merged yet but it works if you do it on the cfg file.

I haven’t had time to mess with RetroArch until just now, so I’m sorry for the late response.

It doesn’t look as if this has been merged yet. I tried manually adding the input lines to the main config file based on the names you gave the binds (“menu_ok”, “menu_cancel”, etc.), but nothing came of that. Adding “input_” before the lines or specifying “_btn” afterwards does nothing to help.

Or did you mean applying the given changes to the source config files and building RetroArch from that, then adding the lines to the program’s config file?

You would have to checkout that pull request and compile yourself this hasn’t been merged

The basic functionality for this (no gui) is already in master so it should be on the next nightly

Well speak of the devil. I mention it now and just a couple of hours later it gets merged! It’ll be interesting to check it out. I juggle with different input sets for different systems, so having one unified menu control set will be a great convenience. Thank you!

Actually I asked SP to merge the non-gui part of this.

Not as coincidental as I thought, then. Still, thanks a lot for this!

Upon testing this, I’ve found that the binds for the menu items still seem to be dependent on what button binds you have in-game. For example, in my NES setup button “0” corresponds to the 360 pad’s X button. For these games I use X for B and A for A, mimicking how most developers bound controls for NES-style games on SNES. For my SNES setup, though, I use the default control layouts. In this case, “0” now corresponds to the 360 pad’s A button.

I can work around this by figuring out which button means what under each configuration, but I’m curious as to what part of the code might be causing this behavior.

Everything uses the retropad. So if you change your CONTROLLER <==> RetroPad binding it will still mess with your binds The idea would be to map controller to retropad, and use core input mapping and this feature, not change the retropad buttons

I hadn’t even noticed core input mappings was a thing. That’s nifty. Now I’ve got my controller setups in an even less convoluted manner than ever before!

One more thing I noticed: These menu control options change the controls for all input types, not just controllers. The keyboard controls in the GUI change along with the controller’s controls.

Yes, again, everything maps to retropad

Oh, you mean the custom GUI mappings map to RetroPad. Got it. I guess that means redefining just GUI controls for just the keyboard isn’t doable as things currently stand.

[QUOTE=Radius;21721]Reversed in the GUI when comparing EmulationStation and RA? It’s just that the behavior is different between them, basically a different convention[/QUOTE]

The defaults in RA with Xinput have certainly changed recently, I think A and B “have” actually switched but as I started using Emulation Station recently I’m not really certain. BUT, and easy spot is the “start” button, which is now mapped to select by default on the 360 controller.