Guide: Advanced Controller Mappings

[spud11]

@PMac10000 Hi. You are doing very well on this.

Yes, to your question. "....so it makes sense to define a common keyboard map for all the buttons in Retroarch, and then configure Mame and Xboxdrv to match the keyboard. Is that right?" Yes.

Just off to work, but things to note:

(a) Not sure about the driver or resource busy error;
(b) Unlike lr-mame2003, FBA doesn't use the TAB interface. With FBA, it should be enough just to map the keys in Retroarch and in xboxdrv;
(b) You need to add the actual keymapping to your xboxdrv command. The 2 lines that you need (with modifications at least to the "button mapping" because you have 6 buttons whilst I have 10) are:

--ui-axismap X1=KEY_LEFT:KEY_RIGHT,Y1=KEY_UP:KEY_DOWN \
--ui-buttonmap a=KEY_LEFTCTRL,b=KEY_LEFTALT,x=KEY_SPACE,y=KEY_LEFTSHIFT,lb=KEY_UNKNOWN,rb=KEY_UNKNOWN,back=KEY_UNKNOWN,start=KEY_UNKNOWN,back+rt=KEY_SPACE+KEY_ESC,lt=KEY_5+KEY_1,rt=KEY_6+KEY_2 \

[A Former User]

@mediamogul said in Guide: Advanced Controller Mappings:

Something that's always bothered me about launching xboxdrv using runcommand-onstart.sh is that it makes using the Runcommand menu itself somewhat impossible. This is because the xboxdrv mapping is made active before the Runcommand menu appears, therefore interfering with the expected control scheme. Over the weekend, I've been experimenting with some ways around this.

First, I tried scripting the xboxdrv command not to launch until it detected that the intended emulator/port had launched. This worked well, except the script needed the specific executable name for the software it was looking for, making everything a little more laborous to set up than I felt it needed to be. I was prepared to live with it, until I noticed that AdvanceMame refused to recognized an xboxdrv simulated mouse event unless it was present before it launched. Seeing as how I play many games that rely on analog controls, it was important enough for me to rethink the approach.

What I needed was something that could be discovered from the runcommand-onstart.sh script that signals the launch of the Runcommand menu, yet yet also signals it's closing before the emulator/port software is launched. After taking a look at /opt/retropie/supplementary/runcommand/runcommand.sh, it looked as though it invoked and exited joy2key.py in exactly the way I needed. With a little more experimenting, I came up with the following that uses the xboxdrv example from the first section of my guide.

if [ "$2" = "advmame" ]; then
sudo killall > /dev/null 2>&1 xboxdrv
j2kpid="0"
until [ "$j2kpid" -gt "0" ]; do
j2kpid=$(pgrep -f joy2key.py)
sleep 1
done
while s=$(ps -p "$j2kpid" -o s=) && [ "$s" ] && [ "$s" != 'Z' ]; do
sleep 1
done
/opt/retropie/supplementary/xboxdrv/bin/xboxdrv > /dev/null 2>&1 \
	--evdev /dev/input/by-id/[•] \
	--silent \
	--detach-kernel-driver \
	--force-feedback \
	--deadzone-trigger 15% \
	--deadzone 4000 \
	--mimic-xpad \
	--evdev-absmap ABS_[•]=x1,ABS_[•]=y1,ABS_[•]=x2,ABS_[•]=y2,ABS_[•]=lt,ABS_[•]=rt,ABS_[•]=dpad_x,ABS_[•]=dpad_y \
	--evdev-keymap BTN_[•]=a,BTN_[•]=b,BTN_[•]=x,BTN_[•]=y,BTN_[•]=lb,BTN_[•]=rb,BTN_[•]=tl,BTN_[•]=tr,BTN_[•]=guide,BTN_[•]=back,BTN_[•]=start
fi &

This waits for joy2key.py to launch, gets it's PID and then waits for it to end before launching whatever emulator/port is being launched (advmame in this example). So, in effect, you can now launch a game, use the Runcommand window as intended if needed and xboxdrv will launch afterwards.

I've talked with so many people about xboxdrv on here that, unfortunately, a lot of it runs together. However, I do remember a few interested parties looking for a way to accomplish this, so I hope it helps. Granted there might be an easier, more effective way, so if anything comes to mind, please feel free to share.

Now that I'm using xboxdrv I'm noticing this as well. Can't change emulators or interrupt launching. I would have thought it was just a change of ordering (show dialog and then do the onstart), but from what you've described, it doesn't seem that straightforward.

[mediamogul]

@telengard said in Guide: Advanced Controller Mappings:

from what you've described, it doesn't seem that straightforward.

To change the order of events more efficiently would require changing runcommand.sh which isn't recommended. I still have the above solution in place and while it's a bit hacky on its face, it works very well. I believe the only thing I added was a final check to see if xboxdrv was active while runcommand.sh isn't. If that particular case ever proves true, then xboxdrv is shutdown, as it means that a gaming session is not active for whatever reason.

[PMac10000]

@spud11 @Riverstorm
Long story short... I gave up on getting the xboxdrv 4-way selective-driver method described here working. I took @Riverstorm 's advice and compiled the lr-mame2003-plus package, which has a convenient 4-way joystick flag that can be enabled for these games.

I verified the 4-way option is present using RA Quick menu. Great! (unfortunately, I'm still having no luck mapping inputs while using lr-mame2003-plus... no buttons or keyboard inputs work, nor TAB for Mame menu. Separate problem...)

In any case, while troubleshooting, I used the standard lr-mame2003 package to launch some 4-way games, and noticed that the 4-way joystick option was also present in the RA Quick Menu! I believe it's only shown as an option when running a 4-way game. I can find no documentation of lr-mame2003 supporting this 4-way flag on GitHub. But yet, there it is...

I've found that gameplay with lr-mame2003 4-way mode enabled has proven a little challenging in Pac-Man style games, and it will take some getting used to. For example... Instead of Pac-Man taking unwanted turns like in 8-way mode, he often just stops at an intersection, unless I've clearly anticipated the turn.

I'm curious if anyone else here has used the 4-way joystick mode in either lr-mame2003 or lr-mame2003-plus, and can compare the gameplay to the xboxdrv method. Thanks!

[mediamogul]

@PMac10000 said in Guide: Advanced Controller Mappings:

I'm curious if anyone else here has used the 4-way joystick mode in either lr-mame2003 or lr-mame2003-plus, and can compare the gameplay to the xboxdrv method. Thanks!

I can't compare the two, as I haven't tested the feature in libretro, but I can say that no such issue exists with the xboxdrv method. Also, seeing as how the directional dropout issue exists on a surprising amount of arcade console ports as well, having an outside universal solution up your sleeve can be very beneficial. For example, my favorite 'Pac-Man' variant is 'Jr. Pac-Man', specifically for the Atari 2600, due to its incredible breakneck pacing. Without a solution for four-way restriction, you'd be hard pressed to ever complete a level.

[Riverstorm]

@PMac10000 - I don't know anyone that has tried both methods to compare (I always had to same question :) and you're correct 4-way is not documented in mame2003.

It was originally developed in mame2003-plus and the devs ported many of features and updates over to mame2003 just recently. They are very similar right now except for a few features and exclusive games that were added to Plus only. It should be pretty easy to test now that it's in 2 cores if anyone has the xboxdrv method setup.

I think I know what you're talking about and occasionally get stuck/stopped turning on ladders in Donkey Kong or get a millisecond lag still but could never quite know for sure and as you said you adapt to it but it doesn't feel 100% correct until you accept it as normal. Funny how the mind works.

Now that others are experiencing some of those same anomalies it might help looking into the issue. The dev @grant2258 that developed the feature loosely calls it "last direction" I believe. He tried a few methods and decided on this one.

Basically the character will continue in the same direction (up, down, left, right) until a new direction (up, down, left, right) is pressed. I think that might leave a bit of room on the stick for a dead spots but I am not 100% sure.

I think of it this way. There's 4 switches that equate to 8 directions. Which are up, down, left and right. The four angle directions are due to two switches being pressed simultaneously like up/right, up/left, down/right and down/left.

When you're moving right in Pac-Man and decide to go up at a corner but instead you hit right/up vs up only I don't think it will make the turn until it's up only. I don't know if that makes sense but I wonder if that's where potential dead spot might be introduced. In true 4-way there is no angle only the four directions which leaves no dead spot.

All this is just theory on my part but the dev that programmed the code would be able to answer it for sure.

[Riverstorm]

@PMac10000 - I don't if it will help but go into RA and then Quick Menu -> Options. Near the bottom set Input Interface to simultaneous and Legacy Remapping to enabled. Then your TAB key should work the same as mame2003 and hopefully allow you to map inputs in m3plus.

[grant2258]

Mame2003-plus has become very difficult for people to understand due to none legacy mode. First thing you want to do in mame2003 plus is update to the latest. Then you need to fix the input changes by deleting mame2003-plus/cfg contents.

the next step is to choose you controller type
options -> Control mapping ; analog_and_digital|digital (directions on lstick or dpad )
if you undestand how mame works this sets you input general too use directions default on dhat or lstick)

to make mame work like you are used to set the following
options Input interface -> simultaneous (i named this mame and mark changed it back to simultaneous)

no allow the mame mapping if you want to access the tab menu
Legacy Remapping (restart) -> enabled

restart you controls will work.

I cant really speak for mame2003 havent tested the feauture on there mark ported it there works like is should in plus.

[grant2258]

on another not just tested the latest mame2003 you will need to delete the mame2003/cfg dir as well the latest updates mark made requires it

[Riverstorm]

@grant2258 - I think he was more focused on this statement:

I've found that gameplay with lr-mame2003 4-way mode enabled has proven a little challenging in Pac-Man style games, and it will take some getting used to. For example... Instead of Pac-Man taking unwanted turns like in 8-way mode, he often just stops at an intersection, unless I've clearly anticipated the turn.

so I replied with this:

I think I know what you're talking about and occasionally get stuck/stopped turning on ladders in Donkey Kong or get a millisecond lag still but could never quite know for sure and as you said you adapt to it but it doesn't feel 100% correct until you accept it as normal. Funny how the mind works.

Now that others are experiencing some of those same anomalies it might help looking into the issue. The dev @grant2258 that developed the feature loosely calls it "last direction" I believe. He tried a few methods and decided on this one.

Basically the character will continue in the same direction (up, down, left, right) until a new direction (up, down, left, right) is pressed. I think that might leave a bit of room on the stick for a dead spots but I am not 100% sure.

I think of it this way. There's 4 switches that equate to 8 directions. Which are up, down, left and right. The four angle directions are due to two switches being pressed simultaneously like up/right, up/left, down/right and down/left.

When you're moving right in Pac-Man and decide to go up at a corner but instead you hit right/up vs up only I don't think it will make the turn until it's up only. I don't know if that makes sense but I wonder if that's where potential dead spot might be introduced. In true 4-way there is no angle only the four directions which leaves no dead spot.

All this is just theory on my part but the dev that programmed the code would be able to answer it for sure.

I can't fully explain how the 4-way mode works or if there's any room for improvement but it seems there's some dead spots in using Pac-Man in his example.

[grant2258]

well need to fix the input issues with the latest mame2003 and plus needs the cfgs deleted because of changes. The latest mame2003 requires the same (i never changed anything on 2003). Since the input cfg files are important that needs dealt with because it can cause issues in itself. He can clarify after he updates.

[Riverstorm]

@grant2258 - I am on the current build, I've wiped all cfg files and see the same issues as he explained above with 4-way but waiting for him to verify is fine, thanks.

[grant2258]

well its simple a 4 way doesnt have a 8 directions it only has 4. so if you go right then press right/up you will keep on going right )or last direction pressed until you commit to another direction.

you cant play 4 way like a 8way the directions simply dont exist. If you want 100% 4 way get a restriction even on a way pressing up/right is a 50/50 what way it will go depending on what way you hold a joystick and how hard you press it. There is no point in prediction it just produces bad directions randomly. Most people seem happy with it but id be happy to remove it if you think its not working. I only added it on request

https://retropie.org.uk/forum/topic/17766/mame2003-plus-hundreds-of-new-games-improved-input-features-new-bugs-now-with-runahead-support/877

the code is here if anyone fancied modding it feel free prs are very welcome.

https://github.com/libretro/mame2003-plus-libretro/blob/0e1506554cc752e814a5b0d493dbf54b396fc238/src/inptport.c#L2665-L2737

[Riverstorm]

@grant2258 said in Guide: Advanced Controller Mappings:

Most people seem happy with it but id be happy to remove it if you think its not working.

Removing the 4-way feature entirely? That sounds a bit extreme, kind of like throwing the baby out with the bath water. He is experiencing dead spots turning corners in Pac-Man. I think he was wondering if there was any improvements that could be made to address the issue and he also asked how the 4-way compared to the xboxdrv method.

[grant2258]

it already been discussed here we are using digital not analog(xbox drive is probably using analog to digital ) no need to repeat what we have discussed earlier. Mame 4 way has to do digital for it to work for people with none analog pads.

https://github.com/libretro/mame2003-plus-libretro/issues/380

[Riverstorm]

@grant2258 - Thanks for the link so we may submit PRs for coding a fix ourselves. I have no idea what could be done to improve it. If I did I wouldn't know how to code it anyway and you know it. You do that all the time to people on the forums here. Linking us to code we don't know how to modify.

Putting your sarcasm aside, I don't believe @PMac10000 listed what type of controller he's using. It might actually help to wait for him to respond before making a bunch of assumptions as he might have some useful information that might help uncover an unknown issue or possible improvement to the existing 4-way code.

[PMac10000]

@Riverstorm @grant2258
Wow, quite a few responses. @grant2258 first of all, thanks for your coding work and in no way am I trying to complain. Rather, I'm happy to do any testing and submit any PRs that may help.

I'm using a Dragonrise USB controller (standard cabinet build with 8-way native joystick, 6 buttons per player). Very similar to @spud11 's setup, who has been very helpful... but I just can't seem to get his xboxdrv 4-way approach configured correctly. Everyone seems to agree xboxdrv 4-way logic is a huge improvement for old-school gameplay.

But the lr-mame2003-plus option seems much more user-friendly to me, if it accomplishes the same thing. I only want to use it for a few old-school games with 4-way joysticks, for better control and less frustration.

I understand the predicament of predictive vs last-direction, when the inputs don't exist... in my current gameplay... using lr-mame2003 (not plus) with the 4-way emulation active, I'm often finding (for example) Pac-Man coming to a complete stop at an "L" or "T" shaped junction, when it "feels" like I made the choice to go in a certain direction before I got there. I guess you'd call it a dead spot. I'll keep playing a few different games and provide feedback. I also need to make the cfg deletions and legacy remapping described above, before proceeding

Thanks all for their contributions.

[grant2258]

@PMac10000 I am using a dragonwise controller with a sanwa joystick. The good news is you can move the restrictor plates in these to make the do a real 4 way.

The problem with the standard restriction plate in these joysticks is there is a long throw (the gap between up and right when you are mid way wanting to choose one). I have a circular restriction in mine now took a while to get used to but plays a lot nicer all with a shorter throw a lot better for shot em ups ect specially is you add a stronger pin in it.

for swapping the the standard sanwa to 4 / 8 way do this.

even with 4 way the throw is long but the restriction helps a lot with any deadzone.

@Riverstorm the code was for the bigger community if they have any better ideas they are 100% more than welcome to try improve things there are many people here that can code just pointed the code out so they can see whats happening if they have a better idea to implement it. I can only see someone trying to implement a analog reader to make a choice unfortunately it wont work on snes and arcade joysticks as they are digital. Well the sanwa can run analog but it still onlly full on or full off

[PMac10000]

@grant2258

Thanks for the tip. I'm aware of the 4-way restrictor possibility, but of course the drawback is that I'd have to take apart my cabinet each time I wanted to play an old 4-way game.... I need 8-way mode for most of the others. So I'm looking for a decent SW solution as opposed to a brute-force HW solution... hopefully one that's easier to implement than xboxdrv. Your work on lr-mame2003-plus seems like the closest thing for my purposes so far.

[grant2258]

you should try it at least once to see how a 4 way plays on you joystick its not that fantastic to begin with try kung fu master it 4 way does take a bit of getting used to when you are familiar with 8 way. I dont think any software solution will get it 100% analog position tracking can get closer but again no use in an arcade joystick or dpad where you just have a button on or off there is no way to track how far they are in between.