snes9x-rpi controls broken? Retroflag Gpi

mitu

@SinisterSpatula If you haven't tried lr-snes9x2002, I suggest you try to see how it performs. xboxdrv may also be a solution for re-mapping the gamepad without any re-compilation - useful for a drop-in configuration.

SinisterSpatula

@mitu Yeah, that's what I'm really puzzled about. I've gotten extremely savvy with xboxdrv and I've used it with many of these older cores now. When I tried using it with this one, it just refused to receive or process any of the key events I sent it, except for two, escape (quit) and backspace (speed up the cpu). And when I connected a bluetooth keyboard and it did the same thing, that's what made me think it must be the core itself. My fork of snes9x-rpi for Gpi is here: https://github.com/SinisterSpatula/snes9x-rpi

SinisterSpatula

I feel like I'm SOOO Close to this now. I was able to modify the code for the joystick detection skipping over Js0 (the retroflag xpad joystick) and get snes9x to grab Js1 instead (xboxdrv joystick). You would think that would be all it takes right? Wrong. So there is some weirdness happening even with that. The button assignments seem to change practically at random. They are one way for one launch, and then they shift around on the next launch. So I'm pretty much abandoning Joystick buttons and going for keyboard input. I know exactly the area of the code I need to change but still working out the best way to change it. It reads like "first we get all the joystick players, and then we get keyboard players". So I think because it was finding joysticks, the keyboard keys became player 2 (which is why none of the movement keyboard keys affected player 1). So if I find away for it to take NO joysticks, the keys should become player 1. That is my current goal.

mitu

@SinisterSpatula Since it uses SDL, just disable the joystick sub-system initialisation - https://wiki.libsdl.org/SDL_InitSubSystem - and see if that leaves you with just the keyboard controls.

spud11

@SinisterSpatula Hi. I use xboxdrv on my 4 player arcade machine where it is really handy, but I'm just wondering what you consider is or will be the benefit of using xboxdrv and snes9x-rpi on the GPI. I received the GPI a couple of days ago and am using one of the standard snes libretro emulators - I'm not sure which because I'm not at home at present. The libretro emulator, though, seems pretty good to me.

pomme

@spud11 The default SNES emulator on the pi zero is lr-snes9x2002 - It runs okay, but has some pretty choppy sound and some slowdown on some of the more demanding titles (at least in my experience). Snes9x-rpi runs extremely smooth on the Retroflag GPi Case. If @SinisterSpatula can get the controls working I'd love to switch emulators.

spud11

@pomme Thanks. That explains it well.

SinisterSpatula

Apparently I missed a very important thing when I went down this rabbit hole of working on snes9x-rpi. There exists "pisnes" and it is based on the same code as snes9x-rpi, and it's much further developed. I have no clue why snes9x-rpi is even a listed emulator on the retropie wiki. So yeah, you should totally switch emulators, but pay no attention to snes9x-rpi. I just wasted a week or more for no reason on it. And I've learned an important lesson. Research every option before you think there is only one. However, if for some reason pisnes still has slow down, I did infact get snes9x-rpi working for the gpi. Maybe try both and see which you like better. You can get my gpi version here (you'll need to compile from source using my repo as the source). modify the snes9x.sh in scriptmodules to point to my repo, then build from source. [removed my fork of snes9x-rpi, just use pisnes instead. It's better in every way.]

spud11

@SinisterSpatula That's really interesting (but am sorry you spent such a lot of time on snes9x-rpi).

I'll install both pisnes and your version of snes9x-rpi and give them both a crack. Did you wind up using xboxdrv too? If so, could I please ask whether you could set out the code you used? Thanks.

SinisterSpatula

@spud11 This is my xboxdrv code for start+select=quit:

#quit (select+start), requires /etc/udev/rules.d/99-xboxdrv.rules
if  [ "$2" = "snes9x" ]
then
    sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv \
    --evdev /dev/input/by-id/usb-RetroFlag_GPi_Case_RetroFlag_01-event-joystick \
    --detach-kernel-driver \
    --silent \
    --force-feedback \
    --deadzone-trigger 15% \
    --deadzone 4000 \
    --mimic-xpad \
    --evdev-keymap BTN_SELECT=back,BTN_START=start \
    --ui-buttonmap back+start=KEY_ESC \
&
fi

SinisterSpatula

@spud11 I just checked pisnes, and yes there is absolutely no reason to ever use snes9x-rpi. Pisnes is exactly the same, and so much better in many ways. I wouldn't even bother with it. [https://www.reddit.com/r/retroflag_gpi/comments/c6wjle/need_help_trying_to_get_snes9x_compiled_for_gpi/espa4wv?utm_source=share&utm_medium=web2x](link url)

spud11

@SinisterSpatula Thanks so much for all of this. You've done some terrific work with xboxdrv. The guru on this forum with xboxdrv is @mediamogul. xboxdrv has so many amazing options.

spud11

@SinisterSpatula Hi. On a new Retropie 4.5 image, I've been playing around with xboxdrv and Vice (the non-libretro Commodore 64 emulator). I've got some working code, albeit it is not perfect. It enables exiting with select + start and entering the F12 menu with select + x. Perhaps best of all though is that there is no need to switch the GPi (using select + left dpad) from hat to joystick/axis modes, which you would otherwise need to do with Vice. (The --trigger-as-button seems to help with this.)

My sdl-vice file which goes in the /opt/retropie/configs/c64/ folder is as follows:

 [C64]
MenuKey=293
MenuKeyUp=119
MenuKeyDown=115
MenuKeyLeft=97
MenuKeyRight=100
MenuKeySelect=102
MenuKeyCancel=101
MenuKeyPageUp=280
MenuKeyPageDown=281
MenuKeyHome=278
MenuKeyEnd=279
SoundDeviceName="alsa"
SoundSampleRate=22050
SoundBufferSize=100
AspectRatio="1.000000"
SDLWindowWidth=384
SDLWindowHeight=272
VICIIVideoCache=0
VICIIDoubleSize=0
VICIIFullscreen=1
VICIIFilter=0
SidEngine=0
SidModel=1
KeySet1North=119
KeySet1East=100
KeySet1South=115
KeySet1West=97
KeySet1Fire=102
KeySet2North=121
KeySet2East=106
KeySet2South=104
KeySet2West=103
KeySet2Fire=107
JoyDevice1=3
JoyDevice2=2
Mouse=1
ETHERNETCARTBase=56832
Acia1Base=56832

The xboxdrv code is as follows:

if [ "$2" = "vice-x64" ]
then
    sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv >> /dev/shm/runcommand.log 2>&1 \
    --evdev /dev/input/by-id/usb-RetroFlag_GPi_Case_RetroFlag_01-event-joystick \
    --detach-kernel-driver \
    --silent \
    --force-feedback \
    --deadzone-trigger 15% \
    --deadzone 4000 \
    --mimic-xpad \
    --trigger-as-button \
    --evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RX=x2,ABS_RY=y2,ABS_Z=lt,ABS_RZ=rt \
    --ui-axismap X1=KEY_A:KEY_D,Y1=KEY_S:KEY_W \
    --evdev-keymap BTN_SOUTH=a,BTN_EAST=b,BTN_NORTH=x,BTN_WEST=y,BTN_TL=lb,BTN_TR=rb,BTN_THUMBL=tl,BTN_THUMBR=tr,BTN_MODE=guide,BTN_SELECT=back,BTN_START=start,BTN_TRIGGER_HAPPY3=du,BTN_TRIGGER_HAPPY4=dd,BTN_TRIGGER_HAPPY1=dl,BTN_TRIGGER_HAPPY2=dr \
    --evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \
    --ui-buttonmap b=KEY_F,y=KEY_Y,a=KEY_W,x=KEY_SPACE+KEY_ENTER,lb=KEY_1+KEY_Y,rb=KEY_2+KEY_N \
    --ui-buttonmap back=KEY_ESC,start=KEY_SPACE+KEY_ENTER,back+x=KEY_F12,back+b=KEY_Y,back+a=KEY_N,back+start=KEY_LEFTALT+KEY_Q \
    --ui-buttonmap du=KEY_W,dd=KEY_S,dl=KEY_A,dr=KEY_D \
&
fi

The keys used are W, S, A, D for movement and F for fire.

On the GPi, the B button is fire and I've mapped the A button to the W key so that for platform games, instead of pushing up on the dpad, you can just press the A button to jump.

I've tested this on Commando Arcade 2015, Berzerk Redux, Aviator Arcade II, Paradroid and Bruce Lee. All work fine. However, Boulder Dash got to the menu screen, but I couldn't get it to actually start the game.

Hope this is helpful.

SinisterSpatula

@spud11 This is awesome! Exciting to see someone else starting to play around with xboxdrv solutions for Gpi. I think right now many people are using lr-vice which for the most part has working controls without xboxdrv, the only issue they were saying was using the keyboard, to hit spacebar on intro screens. I just made a mapping for Duke Nukem 3D yesterday that came out really good. Perhaps we can work together on this stuff, if you're interested? You can find me on the superretropie FB group, and you can checkout any of the xboxdrv scripts I've written on this page (everything is open to use by anyone, you don't have to be in our group): https://sinisterspatula.github.io/SuperRetropieGuides/

spud11

@SinisterSpatula That's no problem at all. I probably won't join the Facebook group but am happy to contribute here and to have a look at the reddit pages.

With lr-vice and vice, the keyboard issue is a problem - more with lr-vice than vice. With vice and the above code, I've mapped some of the more obvious keys to the GPi's buttons, but it would be possible to map every key to one button alone. xboxdrv allows you to cycle through keys by repeatedly pressing a button. It's not a perfect solution but one which could work.

Perhaps more importantly, on reddit, I noticed someone asking about whether it was possible to make individual configurations for individual games. It is. An example would be as follows:

if [ "$3" = "/home/pi/RetroPie/roms/mame-advmame/temptube.zip" ]
then

(I use advmame on my Arcade machine so this is just an example for Tempest Tubes.)

If you haven't already done so, you might also want to check out @mediamogul's Advanced Mapping Guide for tips:

https://github.com/RetroPie/RetroPie-Setup/wiki/Universal-Controller-Calibration-&-Mapping-Using-xboxdrv

I've also installed your Super Retropie Guides which are really fantastic. I like what you did with both the hat and the axis/joystick modes. Addressing both in the one code block was very clever. I had not thought of that.

spud11

@SinisterSpatula The other thing I should add. Like you, I started using xboxdrv to ensure consistency in exiting all emulators. However, I also found that it was useful for old Arcade games which had 4-way (rather than 8-way) joysticks by using the --four-way-restrictor argument.

So for individual games such as Pacman that have 4 way restriction, you could set up an individual xboxdrv configuration with --four-way-restrictor which would resolve any diagonal issues. It is a very effective software solution.

I haven't played too many of the 4-way restricted games as yet on the GPi, so I'm not sure whether this is a problem with the GPi's dpad because it seems to default to the hat mode rather than axis/joystick mode, but I flag it in case people have had trouble with some of the controls for older Arcade games that require a 4 way restricted gate.

SinisterSpatula

Yep the $3 I had future plans to do. I think I'm going to move to the fancy way of doing the maps (where it's building the script on the fly so to speak, by just calling blocks of code, so you only write it once and then use the same code block for different mappings), but I thought that might over complicate things for me, early on. But eventually I want to do that. For right now, I just started a new repo where I plan to start basing the mappings off using the alternate D-pad mode, and moving my mappings out of onstart.sh and using a source command inside it instead, to call my mappings that way. My new repo is at: https://github.com/SinisterSpatula/Gpi2/ everything is updated except for the mappings themselves. (working on that next)

spud11

@SinisterSpatula I think this is a very good idea. Whatever is ultimately easiest for you in designing the code and updating it is definitely the way to go. You've really helped (and are continuing to help) the GPi community which is great.

The only thing I'm wondering about is whether using the alternate D-pad method permanently will require people to press the SELECT+DPAD LEFT before they start any game and then switch back to the "normal" method after exiting the game. I stress I didn't need to do that with the vice code I've used so hopefully it won't be the case. It'd be really great if the whole thing winds up completely seamless.

SinisterSpatula

@spud11 Yes it should be seamless, basically, you set the dpad mode once and leave it. Emulationstation will have it's inputs using that mode and so will all the Lr-cores (because they use what emulationstation uses). One thing that is doing my head in, and maybe you can help with, is.. I saw your --ui-axismap X1=KEY_A:KEY_D,Y1=KEY_S:KEY_W \ and that's exactly what I needed to start using the new d-pad mode. It works wonderfully! But now I'm wondering how do this for my more complex uses of the D-pad, like Duke Nukem 3D for example, where before I was able to do a modifier button + dpad to give it an alternate mapping. My old way using the other d-pad mode was to do this (looking at Duke mapping):

#Duke Nukem
if [ "$2" = "eduke32" ]
then
    sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv \
    --evdev /dev/input/by-id/usb-RetroFlag_GPi_Case_RetroFlag_01-event-joystick \
    --detach-kernel-driver \
    --silent \
    --force-feedback \
    --deadzone-trigger 15% \
    --deadzone 4000 \
    --mimic-xpad \
    --dpad-as-button \
    --no-extra-events \
    --evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RX=x2,ABS_RY=y2,ABS_Z=lt,ABS_RZ=rt \
    --evdev-keymap BTN_SOUTH=a,BTN_EAST=b,BTN_NORTH=x,BTN_WEST=y,BTN_TL=lb,BTN_TR=rb,BTN_THUMBL=tl,BTN_THUMBR=tr,BTN_MODE=guide,BTN_SELECT=back,BTN_START=start,BTN_TRIGGER_HAPPY3=du,BTN_TRIGGER_HAPPY4=dd,BTN_TRIGGER_HAPPY1=dl,BTN_TRIGGER_HAPPY2=dr \
    --evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \
    --ui-buttonmap x=KEY_RIGHTCTRL,a=KEY_E,b=KEY_SPACE,y=KEY_LEFTSHIFT,lb=KEY_A,rb=KEY_D,a+lb=KEY_SEMICOLON,a+rb=KEY_APOSTROPHE,lb+rb=KEY_LEFTCTRL,rb+lb=KEY_LEFTCTRL \
    --ui-buttonmap start=KEY_ENTER+KEY_M,back=KEY_ESC,back+start=KEY_F10 \
    --ui-buttonmap du=KEY_UP+KEY_W,du+a=rel:REL_Y:-5:5,a+du=rel:REL_Y:-5:5,dd=KEY_DOWN+KEY_S,dd+a=rel:REL_Y:5:5,a+dd=rel:REL_Y:5:5,dl=KEY_LEFT,dr=KEY_RIGHT \
    --ui-buttonmap start+y=KEY_J,start+b=KEY_N,start+x=KEY_H,start+a=KEY_TAB \
&
fi

Any idea what that might look like with the new d-pad mode?

SinisterSpatula

By the way, du+a and a+du looks repetitive, but I actually found it works better, because this way it does not matter if the player pushed A first, or direction up first. Both ways get the "shifted output".