new mame2010 folder structure

markwkidd

@markwkidd said in new mame2010 folder structure:

~~My plan is to have the mame2010 core create these folders if they do not exist, but that functionality is not working in a cross-platform way yet. For now these folders need to be created manually.~~

Follow-up: as of today, the new folder creation code is merged into the mame2010 upstream source. @msheehan79 has done preliminary testing on an rpi (thank you!) and it seems to be working. Please feel free to post & tag me if you're using the updated mame2010 and you are having an issue with your folder/path structure.

mediamogul

@markwkidd

In the new README.md it makes reference to the older cheat.dat file, but I believe it should be cheat.zip for several versions after 0.126, including 0.139 (Mame2010). Somewhere along the line it even changed again to cheat.7zip.

markwkidd

@mediamogul said in new mame2010 folder structure:

@markwkidd

In the new README.md it makes reference to the older cheat.dat file, but I believe it should be cheat.zip for several versions after 0.126, including 0.139 (Mame2010). Somewhere along the line it even changed again to cheat.7zip.

Oops. Even though I'm the one who added the cheat.zip file to the metadata
folder I was back in mame2003 land when I wrote that. Thank you!

edit: PR https://github.com/libretro/mame2010-libretro/pull/90

mediamogul

@markwkidd

Well it compiled, but technically failed with the error:

Could not successfully install Arcade emu - MAME 0.139 port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mame2010/README.txt not found).

However, after relocating my previous files to the new directory locations, everything launched and ran well without the troublesome readme file. 'Gorf' made use of it's hilarious samples, but was in the wrong aspect ratio until I changed the core option from 'DAR' to 'PAR'.

Unfortunately, the bad news is that lr-mame2010 no longer supports MAME artwork with this update. I imagine this is because Retroarch uses it's own overlay system, but certain games rely on MAME's interactive artwork to complete some of the original play mechanics, such as the ranking panel in 'Gorf' that illuminates to let you know what rank you're up to. RetroArch's built-in overlay system doesn't allow anything that advanced, so it's a shame to see MAME's implementation gone. Other than that and the minor issue of aspect ratio correction, everything seems peachy. It's great to see this core getting some updates. Nice job and thanks to all involved.

markwkidd

@mediamogul said in new mame2010 folder structure:

@markwkidd

Well it compiled, but technically failed with the error:

Could not successfully install Arcade emu - MAME 0.139 port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mame2010/README.txt not found).

However, after relocating my previous files to the new directory locations, everything launched and ran well without the troublesome readme file. 'Gorf' made use of it's hilarious samples, but was in the wrong aspect ratio until I changed the core option from 'DAR' to 'PAR'.

Unfortunately, the bad news is that lr-mame2010 no longer supports MAME artwork with this update. I imagine this is because Retroarch uses it's own overlay system, but certain games rely on MAME's interactive artwork to complete some of the original play mechanics, such as the ranking panel in 'Gorf' that illuminates to let you know what rank you're up to. RetroArch's built-in overlay system doesn't allow anything that advanced, so it's a shame to see MAME's implementation gone. Other than that and the minor issue of aspect ratio correction, everything seems peachy. It's great to see this core getting some updates. Nice job and thanks to all involved.

If you have time, could you possibly tell me what I need to recreate a mame2010 overlay that stopped working? I imagine I need the artwork file itself but in addition to that could you tell me what settings are involved, etc?

I have never used MAME overlays myself but I would be glad to see if I can keep that working with the new code.

markwkidd

@mediamogul said in new mame2010 folder structure:

Well it compiled, but technically failed with the error:

Could not successfully install Arcade emu - MAME 0.139 port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mame2010/README.txt not found).

Here's my reply #2 .This needs to be resolved in RetroPie-Setup, although I caused it :). I have submitted a PR here: https://github.com/RetroPie/RetroPie-Setup/pull/2308

When I looked at that part of the RetroPie-Setup code, I am concerned that it may not be automatically locating mame.ini to the correct folder now. I can't see a path indicated there, so I don't now how to tell where it gets sent.

mediamogul

@markwkidd said in new mame2010 folder structure:

could you possibly tell me what I need to recreate a mame2010 overlay that stopped working?

Sure. I'll continue to use 'Gorf' as an example because I'm familiar with it. Surprisingly, before this update, you really didn't need an artwork file, just the ROM itself. I'm guessing that means that the simulated ranking panel MAME generates is somehow generated from artwork within the actual ROM. However, 'Gorf' does indeed have it's own art file overlay as well that cosmetically completes the rest of the panel. When the standard art overlay is loaded and the game is launched, you can tell that you're intended to see it in the recent update, as the screen has been scaled down by MAME to accommodate the the panel, but everything is just drawn black. So in short, you should really only need the 'Gorf' ROM and art file to test.

markwkidd

@mediamogul said in new mame2010 folder structure:

@markwkidd said in new mame2010 folder structure:

could you possibly tell me what I need to recreate a mame2010 overlay that stopped working?

Sure. I'll continue to use 'Gorf' as an example because I'm familiar with it. Surprisingly, before this update, you really didn't need an artwork file, just the ROM itself. I'm guessing that means that the simulated ranking panel MAME generates is somehow generated from artwork within the actual ROM. However, 'Gorf' does indeed have it's own art file overlay as well that cosmetically completes the rest of the panel. When the standard art overlay is loaded and the game is launched, you can tell that you're intended to see it in the recent update, as the screen has been scaled down by MAME to accommodate the the panel, but everything is just drawn black. So in short, you should really only need the 'Gorf' ROM and art file to test.

I am annoyed that the automatic bezel you were getting from just gorf.zip is not working. If we can figure out what that is called and/or how it works I'd like to see that still work the same way.

Here's what I have been able to do to get a bezel to appear:

move mame.ini to /libretro saves directory/mame2010/ini (making sure that bezels are set to 1 to be enabled)
download the gorf.zip artwork file from Mr. Do's MAME artwork site, place in /libretro system directory/mame2010/artwork

0_1519316236624_Screenshot 2018-02-22 11.16.32.png

mediamogul

@markwkidd

The mame.ini made all the difference. Both with and without the bezel overlay, the rank panel is visible. I took the time to go a round in the game and after the Gorf flagship is destroyed, the panel did in fact change from "Space Cadet" to "Space Captain". This is very keen!

I do have a couple of questions about the mame.ini file though. It's always been my understanding that RetroArch ignores this file for it's MAME cores, but losing these features after the update makes me wonder if there's an errant mame.ini file it was calling to before. If it did exist, do you have any idea where it was being called from? This is partly out of curiosity and partly as a good housekeeping measure to keep superfluous config files from floating around my system.

Also, the mame.ini is usually generated by MAME at the users request and normally isn't a standard part of a base MAME install. Do I understand you right that this file will be automatically created and placed in the proper location when installing from the RetroPie setup script?

My last question is regarding the directory path settings in mame.ini. I didn't want them to conflict with what is set in RetroArch, so I commented them out, but is this a necessary step, or will RetroArch just override these settings. If that's the case, does RetroArch override any other settings found in mame.ini?

markwkidd

My understanding is that best practice for libretro mame cores is to implement all of the mame.ini options as part of the hardcoded port (as in the folder structure) or as libretro core options. I don't think mame2010 ever made it to that point. @msheehan79 has experienced this as well.

@mediamogul said in new mame2010 folder structure:

If it did exist, do you have any idea where it was being called from? This is partly out of curiosity and partly as a good housekeeping measure to keep superfluous config files from floating around my system.

I think RetroPie-Setup was smart enough to copy the boilerplate mame.ini from the github repository to wherever non-conformant place mame2010 was looking for. I don't understand that part of the RetroPie-Setup script yet.

Also, the mame.ini is usually generated by MAME at the users request and normally isn't a standard part of a base MAME install. Do I understand you right that this file will be automatically created and placed in the proper location when installing from the RetroPie setup script?

That's what it seems to be doing. What I would really like to do is move this functionality into mame2010 itself and spawn a minimal boilerplate into the ini folder only if one doesn't already exist there.

I believe I know how to do that based on my recent mame2003 hiscore work.....

My last question is regarding the directory path settings in mame.ini. I didn't want them to conflict with what is set in RetroArch, so I commented them out, but is this a necessary step, or will RetroArch just override these settings. If that's the case, does RetroArch override any other settings found in mame.ini?

My recent patches means that mame2010 will ignore the paths in mame.ini. I've submitted a patch just now to to the boilerplate mame2010 mame.iniso those parts are omitted.

It should be looked as to whether anything else in the mame2010 boilerplate mame.ini no longer is functioning. This is the boilerplate: https://github.com/libretro/mame2010-libretro/blob/master/mame.ini

See also this issue with information from msheehan79: https://github.com/libretro/mame2010-libretro/issues/81

markwkidd

Closed at least one elderly issue, woohoo! https://github.com/libretro/mame2010-libretro/issues/31

mediamogul

@markwkidd

Very informative. Thanks.

markwkidd

I submitted a new PR to automatically generate and place a shortened mame.ini if there is not one in the ini folder: https://github.com/libretro/mame2010-libretro/pull/94

markwkidd

That PR is approved. From here on, if the user doesn't have a mame.ini, a minimal one will be generated in the ini folder. I hope that it has the necessary settings to keep things functional for everyone while not 'stepping on the toes' of the core options.

I also discovered a pretty fundamental bug that somehow doesn't seem to be causing problems in general. It does however throw up an annoying speedbump to implementing 'hiscore' support in mame2010: https://github.com/libretro/mame2010-libretro/issues/95

estefan3112

@markwkidd Hello there, MAME2010 now compiles in Ubuntu 16.04, but MAME does not start any game. Retroarch crashes and Ubuntu just reports back that This package does not seem to be installed correctly." It was a fresh install of the core in Retropie/Ubuntu. On the same machine, this core works in Retroarch for Linux, as precompiled under the Nightly Core Builds. Would an install log help or shall I provide anything else? Cheers!

markwkidd

@estefan3112 said in new mame2010 folder structure:

@markwkidd Hello there, MAME2010 now compiles in Ubuntu 16.04, but MAME does not start any game. Retroarch crashes and Ubuntu just reports back that This package does not seem to be installed correctly." It was a fresh install of the core in Retropie/Ubuntu. On the same machine, this core works in Retroarch for Linux, as precompiled under the Nightly Core Builds. Would an install log help or shall I provide anything else? Cheers!

If you can please post a pastebin link to the install log as well as the retroarch log when it crashes.

estefan3112

@markwkidd Unfortunately the logfile seems to be too large for pastebin. It is 3.6 MB.
You can download it from there:
https://drive.google.com/open?id=1C779_P_o5kk2kr6WhIAMg2JXv0jDaK4g

This is interesting:
https://pastebin.com/2pf3uPRH
The error tells me that no files are there, but the files are there, they all run e.g. with MAME2003, whily MAME2010 does not find them (in the Arcade folder).

Will dig further

dankcushions

@estefan3112 mame2010 uses a different romset to mame2003. what works in mame2003 will almost certainly NOT work in mame2010. you need to get the right romset.

TillmanZ

Seems like I have the same issue with a newly build lr-mame2010 on an Odroid XU4.
I definitely have a matching 0.139 10yard.zip rom but still the core complains that it allegedly cannot find any of the modules (which definitely are inside the ZIP).
With lr-mame2014 (and a matching rom obviously) it works without any issues.

Any idea what might be causing this?

Best,

Tillman

TillmanZ

I can confirm that the issue is definitely caused by the new build.
I have replaced the core with a known-to-be-working build from a couple of weeks ago and all roms work flawlessly.
Only the new build complains about the missing files (all of them) inside the zip.

Best,

Tillman