snes9x-rpi controls broken? Retroflag Gpi

SinisterSpatula

Now I'm wondering if it's better to do an axismap or if I should stick with this method (no axismap). I'm leaning toward no axismap because buttonmap seems to be more flexible, or allows more complexity. (or so it seems, I could be wrong)

SinisterSpatula

It turns out all I had to change was just one line. All of my mappings just needed this:

--evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \

Changed to

--evdev-absmap ABS_X=dpad_x,ABS_Y=dpad_y \

Literally the only change needed.

spud11

@SinisterSpatula Very well done.

Is it possible to combine the two? eg --dpad-as-button \ and --trigger-as-button \ plus, for example, --ui-axismap X1=KEY_A:KEY_D,Y1=KEY_S:KEY_W \ and --evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \ etc?

If not, my recollection is that mediamogul had figured out a way of having 2 separate configurations which can be switched via button press.

spud11

@SinisterSpatula Excellent. My last message crossed with your's.

SinisterSpatula

Hmmm, yes that is something to experiment with for sure. Like, if we wanted to try and support whatever mode the dpad button happened to be? I'm not too sure about that. I'm thinking while that would be cool, how much use would it really be. We don't want people constantly switching their d-pad mode. They really should "set it and forget it". So all my maps are going to be consistent and based on a certain mode. I guess, if it's just that one line that changes, it could be stored as a variable at the top of the file, and used in place of the line, depending on which mode they want it to be.

spud11

@SinisterSpatula You've probably tried this already, but could you have both --evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \ and --evdev-absmap ABS_X=dpad_x,ABS_Y=dpad_y \ in the one configuration? Does it conflict?

SinisterSpatula

@spud11 said in snes9x-rpi controls broken? Retroflag Gpi:

--evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \

OMG! THAT WORKS. I did not try that, I didn't think that would work but it TOTALLY DOES! I can be in game, and switch my D-pad mode and it does not miss a beat. Holy cow. That's lifechanging lol

spud11

@SinisterSpatula Terrific! Your work here is done!!! xboxdrv really is an amazing piece of software.

SinisterSpatula

Hey @spud11 I got my mappings converted into that advanced fancy style (the one from the advanced xboxdrv controls author). It makes me dizzy to look at it, but it works! :) Thank you so much for your ideas, and input, truly epic advancements today :D I will see about including your vice config and seeing if I can (maybe) improve upon it. I also have openbor on my todo list (there's just a basic mapping to work with the menu's right now for that one).

spud11

@SinisterSpatula That's great indeed and I'm glad I could help. I can't wait to see the next iteration you produce.

The advanced mapping method with case statement really works well if you have a lot of code. My arcade machine's runcommand-onstart.sh has about 4,300 lines of code for 4 arcade joysticks, a PS4 wireless controller and an 8BitDo Zero covering about 60 systems. I also use it for all of the libretro cores too now. It doesn't miss a beat, so I reckon you're going down the right path.

Going back to my GPi vice code, with a bit more testing I'm finding that it's definitely not working for every game, so I reckon your newly produced code will be more successful than mine in "universalising" the controls for the c64. Please feel free to experiment with my code of course and make any changes you think are best.