libretro control mappings have X and O button labels reversed

[bcat]

Hello! Thanks for awesome emulator! I've recently been playing the libretro core on my Anbernic RG35XX. It's a similar form factor to the Miyoo Mini Plus, and someone on the Retro Handhelds Discord has made a recent build of the core (version 0.0.2.20).

One thing I noticed is that the X and O button labels in the RetroArch controls settings seem to be swapped vs. what actually gets sent to the game. Sorry, it's kind of a long report since there's multiple levels of input mapping (device => RetroPad => libretro core => game).

TL;DR: I think these two array entries are swapped, causing them to do the opposite of what the RetroArch controls UI says they do.

(Just to be explicit, I'm not saying the choice of which physical button position is X vs. O is wrong, since I guess that's probably subjective. The bug is just that whatever physical layout is actually used, the RetroArch UI displays the opposite layout for this core. 😄)

Device => RetroPad

The RG35XX uses an SNES-style button layout (A button on the right, etc.), so the physical buttons on the device match the RetroPad names (which are also based on SNES):

RetroPad => libretro core

By default, the FAKE-08 libretro core claims to map buttons as follows:

libretro core => game

I'm testing with Celeste Classic. It uses buttons as follows:

• PICO-8 Button O (keyboard keys Z, C, N in the official app) => Jump
• PICO-8 Button X (keyboard keys X, V, M in the official app) => Dash

End result

So in Celeste, the end-to-end mappings should be as follows:

• RG35XX Button B (Down) => RetroPad Button B (Down) => PICO-8 Button O => Jump
• RG35XX Button A (Right) => RetroPad Button A (Right) => PICO-8 Button X => Dash

But in practice, I see the opposite behavior. Device Button B dashes and device Button A jumps. The labels presented in the RetroArch control settings appear to be swapped vs. reality.

Digging into the code a bit, it looks like maybe the mapping from RetroPad buttons to PICO-8 buttons has reversed X and O compared to the indices of the PICO-8 buttons themselves.

So that button mapping in the core should be changed (which would make the actual button mapping match what the RetroArch UI shows). Alternatively, if the button mapping is intended and the UI is just wrong, the button labels in RetroArch settings should be swapped instead.

[jtothebell]

Thank you for this detailed report, and sorry it took me a while to take a look at it. It does look like you are right, and I think your first suggestion is the best fix, so I've just pushed that change (https://github.com/jtothebell/fake-08/commit/b0f0f424b7cd4b53d4a7181e5677ea44747bf661). I don't have a 35XX or toolchain for to build and test it, but the change should be available now if you or someone else are able to build and test it.

[bcat]

Hey, thanks for the fix! I don't have a build environment set up for RG35XX, but there's a couple different toolchain repos I've found, so I'm going to try and do a build sometime in the next few days (depending on when have some spare time to poke at it).

Also, for my own reference later, some useful info on building (including Makefile w/ flags) in the comments of this Reddit post.

[bcat]

Someone who rebuilds various cores for the RG35XX was nice enough to build a binary with the fix patched in, and I can confirm it works, so I'll close out this particular issue.

But interestingly, they say the latest Git HEAD gives errors ("Unknown Cart Format") for the libretro core. So that sounds like a different bug.

Really what I need to do is figure out how to contribute an RG35XX makefile to this repo so that core can be built upstream. (It's supposed to be pretty similar to the Miyoo Mini toolchain.) But I haven't found cycles to figure that out yet, sorry.