Using xboxdrv with mame4all/advmame

mediamogul

@lummox-jr said in Using xboxdrv with mame4all/advmame:

Is it possible we're using different advancemame versions? I'm using AdvanceMAME 3.

I'm using the latest version of 3.x, which is currently 3.8.

do you have no mouse (normally) in use, like me? If you run the advm command does it say no mice were found?

I have a standard mouse attached as well and I don't get the error message.

My xboxdrv command has no --device-name option but I assume that's not important.

That shouldn't matter, no.

I haven't mapped the analog sticks to keys. (I could, but I'm hoping I can attain finer control via the mouse.)

This likely isn't the source of you problem either, but something to keep in mind is that you'll only get finer movement by mapping mouse movement to an analog stick on games that support it. In all other games, the stick will be ignored. That's why I have it on a toggle. For games that use 4/8-way directional input, the stick is key-mapped, but when toggled, mouse movement is enabled for games that support an analog range like trackball games and the like.

Your problem hasn't left my mind and I'm still thinking on it. Later this evening I'll read back over the thread to see if we've missed anything.

Lummox JR

@mediamogul said in Using xboxdrv with mame4all/advmame:

do you have no mouse (normally) in use, like me? If you run the advm command does it say no mice were found?

I have a standard mouse attached as well and I don't get the error message.

I thought that might be the smoking gun, so I just tried attaching a mouse. That didn't make a difference in advmame itself, although advm did see the mouse. When I tried it with the xboxdrv command in place, the mouse output from the driver doesn't show up in advm either.

For completeness' sake, I also did a test with the keyboard unplugged to see if xboxdrv key output worked, which it did. That's good, since once the system is in my living room I don't intend to have a keyboard in use most of the time.

Annoyingly advmame (I believe I'm also using 3.8) is somewhat crashy with this Star Wars rom set, so I might try going back to mame4all to see if that behaves any better. Same problem remains though: neither one sees the xboxdrv mouse output, and now I know that's true even when a real mouse is attached.

mediamogul

@lummox-jr said in Using xboxdrv with mame4all/advmame:

Annoyingly advmame (I believe I'm also using 3.8) is somewhat crashy with this Star Wars rom

That could be a red flag right there. I play 'Star Wars' pretty frequently and I've never known it to crash. Afterwards, does it report any issues to /dev/shm/runcommand.log?

Lummox JR

@mediamogul Unfortunately the log gets erased with every new play, and at the moment I'm unable to reproduce any crashes/errors at all. Very weird.

I still can't figure out why the mouse output won't work though. Everything in my setup says it should.

mediamogul

@lummox-jr said in Using xboxdrv with mame4all/advmame:

I still can't figure out why the mouse output won't work though. Everything in my setup says it should.

I've looked back over everything and it's a mystery to me as well. My only guess is that something has been missed in transcribing the settings and logs here verses copying and pasting. One very important step we skipped with you is to gather your system info. In most cases, that can open up some possibilities. The required information is detailed at https://retropie.org.uk/forum/topic/3/read-this-first

spud11

@lummox-jr Can you confirm that the keyboard mapping does work properly in Star Wars with advancemame? It sounds like it does, from your more recent comments.

One thing about mapping the keyboard with xboxdrv is that you can't really go wrong with it. Once you've tied the joystick direction or button to the right key, that's the end of it. It'll just work.

However, I'm wondering whether the mouse mapping really operates in the same way. When in doubt, try the "shotgun" approach. Theadvmame.rcallows up to 8 players (at least mine has 8), so perhaps replicate Player 1's input maps for each player eg in my case:

input_map[p1_mousex] mouse[0,x] mouse[1,x] mouse[2,x] mouse[3,x]
input_map[p1_mousey] mouse[0,y] mouse[1,y] mouse[2,y] mouse[3,y]

input_map[p2_mousex] mouse[0,x] mouse[1,x] mouse[2,x] mouse[3,x]
input_map[p2_mousey] mouse[0,y] mouse[1,y] mouse[2,y] mouse[3,y]

And so forth for all 8 players and then test. It can't do any harm to try this anyway, given that nothing else has worked so far.

Lummox JR

@mediamogul Here's my system info:

Raspberry Pi model 3 B+
Power supply: 5V 2.5A
RetroPie version: 4.4.2
Built from: image pre-installed on SD card, but updated from binaries via RetroPie-Setup script
USB devices connected: Keyboard, controllers (currently just 1), rarely mouse (not currently connected, but tested with this setup)
Controller used: Generic 2-analog-stick game controller with D-pad. For general use, I use basic SNES-style controllers that have no analog or triggers.
Error messages received: None.
Guide used: https://github.com/RetroPie/RetroPie-Setup/wiki/Universal-Controller-Calibration-&-Mapping-Using-xboxdrv
File: /home/pi/RetroPie/roms/arcade/starwars.zip
Emulator: mame4all, advmame

I have been periodically updating RetroPie and other core packages via the setup script. This system is quite new; I'm not sure if it came with 4.4.2 or if that was an update. I had to install advmame as an optional package (also installed advmame 0.94 and 1.4. just to try it).

There is one thing I feel I should mention that occurs frequently with the controller I'm currently testing. Often (possibly always), the first time I boot up and try to run Star Wars, xboxdrv fails with a message about calling a pure virtual method, none of the keyboard output works, and then when I come back to emulationstation the joystick is no longer operating. If I exit ES, I check /dev/input or evtest and find the gamepad is no longer listed. If I unplug it and plug it back in, everything works normally again and does not recur the entire time the system is running. I don't believe this ever happened with the SNES-style retropad, only with the generic one I'm trying to configure that has the analog sticks.

The error message happens before the runcommand delay box appears, and also the message says it's happening within rc.local. The default xboxdrv line is in the /etc/rc.local file, and I hadn't touched it. (I am not calling that command again in runcommand-onend when restoring the devices to normal. It doesn't seem to be an issue.) Removing it does not seem to cause any problems and when I tried that again just now, I didn't get the error when I started Star Wars.

However I did get a crash in advmame when I forgot and pressed start instead of the fire button.

Double signals, 11 and 11
Signal SIGSEGV[MAPPER], fault at 0x73e15050, from code at (nil)
Compiled Jul  1 2018, 19:04:38

I couldn't cause crashes to occur on subsequent runs in the same boot session.

mediamogul

@lummox-jr said in Using xboxdrv with mame4all/advmame:

Built from: image pre-installed on SD card, but updated from binaries via RetroPie-Setup script

This is another potential explanation for your issues. Pre-built systems by third parties very often have inexplicable problems that can't be accounted for. What's more, they're also impossible to troubleshoot, as there is no way of knowing what all has been altered. Because of this, we have a strict policy against offering support for these third party setups here.

At this point, the only suggestion I can make to move forward is to reinstall RetroPie using the official image. I would also recommend re-configuring your network to allow a direct connection to your Pi so that you can troubleshoot these types of issues more effectively. I had to rework my entire network configuration about two weeks ago, so I know it's a pain. However, as it stands, you're working at a huge disadvantage by not being able to fully relay the exact contents of these configuration files and error logs.

Lummox JR

@mediamogul said in Using xboxdrv with mame4all/advmame:

At this point, the only suggestion I can make to move forward is to reinstall RetroPie using the official image. I would also recommend re-configuring your network to allow a direct connection to your Pi so that you can troubleshoot these types of issues more effectively. I had to rework my entire network configuration about two weeks ago, so I know it's a pain. However, as it stands, you're working at a huge disadvantage by not being able to fully relay the exact contents of these configuration files and error logs.

Yeah, redoing my network is something I'd like to do at some point anyway to simplify working with some things, but it's not something I'm prepared to do right away. Nor is re-flashing the SD card, although I recognize that would simplify a few things. (I'd have to save some of the info I've already setup, like my onstart/onend scripts, but that's okay.) I may have to go forward with the system as it is now and look into getting the rest of this working at a later date.

icebear81

Was there any resolution to this? I just got a GRS Yoke and the DEADZONE is killing any usability of this.