MAME development: lr-mame2003 Updates

BuZz

Thanks! I have updated the binaries.

caver01

@dankcushions I just recompiled and I am going through my spinner/trackball games. So far so good! I am just getting started, but Cameltry, Centipede, Millipede all working nicely. The trickier titles like Off The Wall (sente) and Blasteroids should be interesting. There are some vector titles the will have to remain with AdvanceMAME (Tempest, Star Trek, Omega Race), but this is FANTASTIC to see many of these finally playable in 2003!

caver01

@caver01 Ok, I have tested a few games and here's what I have found:

For all non-vector, single-player spinner games and trackball games lr-mame2003 will become the standard. For two-player games (dual spinners) player 2 can't participate. Player one works fine using the x-axis of a spinner interface, but where I would expect player 2 to use the y-axis, no inputs register. It's as if the Player 2 Dial isn't mapped to anything.

This affects any head-to-head games like Blasteroids, Off The Wall (Sente) as well as driving games like Championship Sprint and Ironman Stewart's Super Off-Road and probably many others.

I expect there is a default mapping coded that maps Player2 DIAL to another axis of a non-existent input.

mediamogul

@dankcushions

I know it's not listed above, but not too long ago there was talk that artwork was possibly enabled in this update as well. I currently have version appropriate artwork files located at ~/RetroPie/BIOS/mame2003/artwork/ and they are not being loaded. Before I start to troubleshoot the issue, is it known whether or not artwork is a possibility yet? Most of my experience with Mame is with the later versions and the option to enable artwork hadn't been yet added to the tab menu in 2003, so if it simply needs to be enabled, how would this be done?

Edit: I've emphasized my appreciation on your work here before, but a whole-hearted thanks is always worth repeating. So, thanks again!

Ender519

@dankcushions

Hey, really appreciate all the hard work! I am following up on sample sounds, I still cannot get them working. All the zip files are located in /home/pi/RetroPie/BIOS/mame2003/samples, and these are the same sample files I used for mame4all, previously.. meaning I took a working setup for mame4all and then loaded 0.78 romset and simply moved these samples over for mame2003. I updated from source, and testing with Donkey Kong, the sample sounds do not work, for example. I have seen some debate over exactly where these samples should go, but I used the path that the documentation had.

This may not be your area either but.. In my troubleshooting, I tried to remove and re-add mame2003 in retropie_setup.sh and when you do that, it only lets you install from source, not from binary anymore, and install from source errors out, leaving me without mame2003 and having to start over again.

Any suggestions? I'm going to rebuild latest RetroPie from scratch I guess.. but I'd love to be able to come out of this with working sample sounds on mame2003

dankcushions

@Ender519 I'm not sure about your reinstall issue, but installing by binary should fix your samples problem. can you try again? also, what what error do you get when you install via source? the full log is kept in /home/pi/RetroPie-Setup/logs/ (then look for the latest date)

Ender519

@dankcushions For various reasons I'm rebuilding to stock RetroPie 3.8.1, so I've lost those logs figuring it was an issue with my build. But in the menu, I no longer had an option for Install from binary, it was gone and the only install option was from source, but that would error out and complain about a missing .so file. If I run into it again I'll get the output verbatim and steps to reproduce.

Back to sample sound issues, assuming that my information about where to put the samples is correct, I will go about it as follows: without updating anything I am going to load mame2003 rom's and samples and see what I get. Then I'll freeze the pi so I can go right back to it and gingerly update the components (distro, and then all packages by binary using latest retropie script), and if I get to a point where it was working and now it's not, I will report back with some better information.

dankcushions

@Ender519 said in MAME development: lr-mame2003 Updates:

@dankcushions For various reasons I'm rebuilding to stock RetroPie 3.8.1, so I've lost those logs figuring it was an issue with my build. But in the menu, I no longer had an option for Install from binary, it was gone and the only install option was from source, but that would error out and complain about a missing .so file. If I run into it again I'll get the output verbatim and steps to reproduce.

Back to sample sound issues, assuming that my information about where to put the samples is correct, I will go about it as follows: without updating anything I am going to load mame2003 rom's and samples and see what I get. Then I'll freeze the pi so I can go right back to it and gingerly update the components (distro, and then all packages by binary using latest retropie script), and if I get to a point where it was working and now it's not, I will report back with some better information.

cool, thanks :) you'll still have to update lr-mame2003 after installing 3.8.1, fyi. there is a known bug with samples with the current version (the one fixed by my updates in the first post), which will per part of later retropie versions, but until then you'll have to do the update. after that i'd expect them to work fine as per the instructions here: https://github.com/RetroPie/RetroPie-Setup/wiki/lr-mame2003#samples

dankcushions

@caver01 said in MAME development: lr-mame2003 Updates:

@caver01 Ok, I have tested a few games and here's what I have found:

For all non-vector, single-player spinner games and trackball games lr-mame2003 will become the standard. For two-player games (dual spinners) player 2 can't participate. Player one works fine using the x-axis of a spinner interface, but where I would expect player 2 to use the y-axis, no inputs register. It's as if the Player 2 Dial isn't mapped to anything.

This affects any head-to-head games like Blasteroids, Off The Wall (Sente) as well as driving games like Championship Sprint and Ironman Stewart's Super Off-Road and probably many others.

I expect there is a default mapping coded that maps Player2 DIAL to another axis of a non-existent input.

thanks for testing! ok, i was hoping to fix this by duplicating the mouse input to player one and 2. however, i did this and tested blasteroids and it just duplicated player1's x axis for both players. i need to have a deeper look to try and see if i make it possible to use the X axis for player 1, and Y for player 2. it seems this is how advmame handles this?

@mediamogul i will look into artwork :) apparently it works but i've not tried it, so i'll investigate and then put some full instructions on the wiki, assuming it works still!

mediamogul

@dankcushions said in MAME development: lr-mame2003 Updates:

so i'll investigate and then put some full instructions on the wiki, assuming it works still!

Fantastic! Thanks.

Ender519

@dankcushions After going to stock 3.8.1, samples worked. After updating distro and binaries, samples still work. Don't know what happened with the prior build but I can confirm it all works. Thanks!

caver01

@dankcushions said in MAME development: lr-mame2003 Updates:

i need to have a deeper look to try and see if i make it possible to use the X axis for player 1, and Y for player 2. it seems this is how advmame handles this?

AdvanceMAME provides very flexible control over mouse input mapping. Using the config file, you can essentially matrix any input (or combination of inputs) to any player control for any ROM (specified ROM, group of ROMs or a default setting overall). This is an ideal situation in principle, as I can assign a specific axis of a specific USB mouse to to a specific player control (i.e. assign the inverted y-axis of mouse2 to the DIAL input of Player 2 for otwalls). It allows for some complex (and expensive) builds. For instance, I could build a three trackball panel for Rampart, or setup three different spinners for Super Off-Road. However, in practice (at least for DIY arcade system builders) this level of flexibility, although convenient, is probably overkill. I've never seen a build that includes more than one trackball. Two spinners is admittedly indulgent, but it makes sense because the interface boards are often built to support a trackball OR two spinners—so if you have one, you are already setup to use two, and if you add a second, it will be on the other axis of the same mouse.

I'm sure someone out there has their spinners on separate interfaces (different mice). Or, how about this use case: Player 1 uses a trackball to steer on the x-axis (no spinners) so Player 2 needs to use the P2 Joystick. However, the Player 2 car keeps crashing because it is tied to the Y-axis of the trackball being used by Player 1!

If you had to pick a default mapping for Player 2, given the way most people would leverage a single interface for two spinners, you would probably satisfy most cabinet builders with X and Y. And making this a configurable option per ROM might add just enough flexibility for the situations when a trackball makes it inconvenient.

dankcushions

@caver01 I have a fix that seems to work :) https://github.com/libretro/mame2003-libretro/pull/49
hopefully this will be accepted soon.

windows support is now working, which is probably pointless to most people here but yeah :)

caver01

@dankcushions said in MAME development: lr-mame2003 Updates:

@caver01 I have a fix that seems to work :) https://github.com/libretro/mame2003-libretro/pull/49
hopefully this will be accepted soon.

Wow. That's beautiful!

Seriously, @dankcushions your efforts are MUCH appreciated. One by one, the seemingly small reasons for using anything other than lr-mame2003 when selecting a MAME emulator are stacking up! Nice work.

BuZz

agreed - excellent stuff - cheers.

Riverstorm

Thanks Dank for all you've done to whip lr-mame2003 into shape and thanks for an "official" thread to post in. We're going to have to name it lrdc-mame2003 or something! ;)

A quick question. Is it a lot of tweaking to get the left/right analog sticks and the silver center button on a XBOX 360 to work in the TAB setup? It's not a show stopper at all from migrating but it sure is handy for extra configuration flexibility. They do work in mame4all-pi and AdvMAME and I'm so used to using them. Great job with lr-mame2003 your efforts are regal good sir! :)

dankcushions

thanks all! honestly i'm having fun messing about with this stuff :)

@mediamogul i had a look into artwork. i'm fairly sure no-one could have gotten it working before as I had to do a code change, but when it was working there was some kind of corruption going on with the image. almost like the image bpp or image format wasn't working properly. i will look into this more but it's not looking great :(

@Riverstorm thanks :) centre button is probably not possible as it's a libretro limitation. libretro sees all controllers as basically a 360 controller, but that doesn't include the centre xbox button. what you could do is rebind your controller through emulation station, and map the centre button to a button it DOES see that you don't otherwise use (eg, the R3/L3 buttons, used when you click in the sticks?). after that, press TAB and change the general inputs so that 'show UI' (or whatever it's called) is your xbox button (which will show up as R3/L3) in addition to TAB. it's a bit of a hack but i'm not sure of any other way :(

mediamogul

@dankcushions said in MAME development: lr-mame2003 Updates:

i will look into this more but it's not looking great

Hey, do what you can. I'm just glad you're looking into it.

Thanks!

Riverstorm

@dankcushions said in MAME development: lr-mame2003 Updates:

@Riverstorm thanks :) centre button is probably not possible as it's a libretro limitation. libretro sees all controllers as basically a 360 controller, but that doesn't include the centre xbox button. what you could do is rebind your controller through emulation station, and map the centre button to a button it DOES see that you don't otherwise use (eg, the R3/L3 buttons, used when you click in the sticks?). after that, press TAB and change the general inputs so that 'show UI' (or whatever it's called) is your xbox button (which will show up as R3/L3) in addition to TAB. it's a bit of a hack but i'm not sure of any other way :(

Thanks Dank that's actually really clever and would have never though of doing it that way. I am not sure what others do but I use the silver button to pull up my MAME TAB menu.

The other key you need to take in account for joysticks is the Escape key (UI Cancel). If you're in Input (General) the TAB key will only enter and exit the specific menu you're on and you can never get back to the "root" TAB menu to the other options until you exit the game and start it again.

Basically the Escape key (UI Cancel) acts as the back key as well as the exit menu key.

caver01

@Riverstorm said in MAME development: lr-mame2003 Updates:

The other key you need to take in account for joysticks is the Escape key (UI Cancel). If you're in Input (General) the TAB key will only enter and exit the specific menu you're on and you can never get back to the "root" TAB menu to the other options until you exit the game and start it again.
Basically the Escape key (UI Cancel) acts as the back key as well as the exit menu key.

I was thinking about this too, but I have just been navigating using the last menu items "return to previous menu" or what ever they say. It's easy to navigate up and down with this, but not as convenient as the UI Cancel.

Here's an idea: I haven't tried this, but couldn't you map the EXIT function in RetroArch to "nul" and allow the ESC key to behave is it normally does in MAME? That way, UI Cancel would work as well as exit, depending on where you are in the emulator. It's the same kind of conflict we see with the PAUSE key.

This, of course, couldn't be a system-wide config. It would have to be per-core and just for lr-mame2003. You could do a test with a per-rom cfg or drop the nul mapping into the appropriate retroarch.cfg, but it would cause a conflict inside the Arcade config folder where you might still need the RetroArch EXIT function for other cores that use it (i.e. lr-fba-next).