Help batch running arcade games

luckyluca

thanks, unfortunately you tool wouldn't work out of the box for exactly the same reason, i'd like to make use of the runcommand infrastructure for cores/emulators, per-game.

To answer your question: I have a sweet setup but realised a quarter of the arcade roms may have the wrong cores assigned in emulators.cfg and no way of determining what romset they came from.
Easier to batch run for the odd one to check if they fail to launch rather than sourcing files again.

Great idea to use the data output rather than screenshot btw.

If I could automate the runcommand for all roms, so that it read data from emulators.cfg and channeled that through automatically, that would be great.

thanks again

elvis

@luckyluca said in Help batch running arcade games:

I'd like to automate launching one by one all arcade games, wait 30 seconds, take a screenshot, kill retroarch, move to the next game and repeat.

MAME's built in benchmark tool will automatically take a screenshot on the last frame of a benchmark.

"mame -bench 30 romname" will run the game with no visual output to screen, but the internal framebuffer will capture the last frame, which will be at the 30 second mark using that command. It'll end up in the "snap" directory, either underneath the mame binary, or wherever you've configured it in mame.ini.

I can't help you with RetroArch related stuff, I'm sorry. But perhaps that functionality directly in MAME is good enough for what you need.

barbudreadmon

@luckyluca said in Help batch running arcade games:

The idea being to run this for all my arcade games, and use raspi-png to save a screenshot of each game. And then assess all screenshots to determine which games fail to launch, and necessitate a core change.

How about curating your romsets using clrmamepro instead ? If you provide matching romsets to an arcade emulator, it'll usually work. Worst case scenario, you might want to trim the dat files using some criterias included in them, like "status" (anything with "preliminary" status usually doesn't fully work), which is still very easy to do using basic programming skills or existing 3rd party tools (like datutils ?)

luckyluca

I got it to work by borrowing and amending
https://github.com/dankcushions/retropie-auto-testing/blob/master/retropie-auto-testing.sh
(thank you dankcushions!)

The loop now runs runcommand rather than retroarch directly, in order to take advantage of the retropie per-game config infrastructure.

I'm taking a snapshot after 30 secs in order to visually assess whether a game loaded fine with the given core.
I'm also spitting verbose retroarch logs and runcommand logs.

Interestingly enough, when retroarch quits because of the core failing to load a given game, nothing is mentioned in the logs, so it would be hard to spot without screenshot.

Regarding using the right set, whilst I fully agree, this is a single huge arcade folder with mixed full roms spanning from 2003 to 2015 cores.
It is supposed to be hand-tested and curated before I started using it, but I spotted several non-loading games in the last few games which left me a bit perplexed. I'm quite happy with this method of testing to be honest, as I can easily pin point the ones without valid screenshots and manually reassign cores.

Also, this screenshot testing approach is going to be applicable to other systems too, i.e. n64.

Best
Luca

mitu

@luckyluca said in Help batch running arcade games:

It is supposed to be hand-tested and curated before I started using it,...

One of the reasons we don't support 3rd party images loaded with ROMs.

luckyluca

I understand as it makes perfect sense.
In my case, having tailored a set of arcade roms coming from different sets (taking advantage of per-game cores emulator configs in retropie), that is bound to have some mistakes. I'm glad that thanks to dankcushions I was able to programmatically check obvious issues without wasting hours manually.

Edit:
Added one question about Retroarch.
Being OCD, do you think that killing retroarch using a killall -9 retroarch, over and over, would harm my installation? I suppose not.

luckyluca

The modified script worked like a charm, I found looking at snapshots super-useful for debugging purposes, thank you all.

Clyde

However, screenshots doesn't say anything about sound quality or other issues that only arise when actually playing the game. So, be prepared for some suprises later.

barbudreadmon

@clyde said in Help batch running arcade games:

However, screenshots doesn't say anything about sound quality or other issues that only arise when actually playing the game. So, be prepared for some suprises later.

Exactly, and some of them are quite hard to notice even when playing the game :

missing gfx elements (because in the first place you might not know they were there)
wrong game behavior (a very common issue with older romsets & emulators is wrong enemy patterns because of missing MCU dump)

Using some proper compatibility list and fixing your romsets through clrmamepro is just the better approach, by far.

luckyluca

@barbudreadmon

That's a valid point, although I feel so close to completing this, with a few hundred left to check.

Anyway, assuming I was to do this from scratch by sourcing the right roms from scratch based on the shared excel doc (which is amazing by the way), and assuming non-merged sets:

am I right to assume that all rom zips that are actually bioses, such as pgm and stvbios, have no reason to exist in rom/arcade, and should only be present in the retropie bios folder?

And, being as it may, should I use the most recent bios zips?
As for instance, mame 2010 bios files contain exactly the same 2003 content in addition to other roms, so presumably they're preferred?

barbudreadmon

@luckyluca said in Help batch running arcade games:

am I right to assume that all rom zips that are actually bioses, such as pgm and stvbios, have no reason to exist in rom/arcade, and should only be present in the retropie bios folder?

Yes, however "getting the most recent bios and putting it in the bios folder" might cause issues, as an example you were mentioning stvbios, and i'm pretty sure advmame, which you'll probably use to play ST-V games, expects an older version of the bios.

luckyluca

@barbudreadmon
I see, I suppose it doesn't help that both the old and newer version of stvbios.zip contain exactly the same roms (with matching CRC), with the newer version of the zip just containing additional files.

It would be awesome to being able to add bios by emulator version, and have the right bios selected based on the core in use:
Retropie/bios/mame2003/.zip
Retropie/bios/advmame/.zip

barbudreadmon

@luckyluca said in Help batch running arcade games:

I see, I suppose it doesn't help that both the old and newer version of stvbios.zip contain exactly the same roms (with matching CRC), with the newer version of the zip just containing additional files.

Actually you are right, i thought some of the old files had been discarded but they were simply renamed, which shouldn't be a problem since the emulator will base its search on crc. Well, stvbios was a bad example then, but there might be newer bios that doesn't contain older files.

@luckyluca said in Help batch running arcade games:

It would be awesome to being able to add bios by emulator version, and have the right bios selected based on the core in use
Retropie/bios/mame2003/.zip
Retropie/bios/advmame/.zip

I can't tell you about the mame cores, but that's exactly what i did in the FBNeo core to avoid conflicting bioses.

luckyluca

Thanks, just wanted to add that I've been involved in using and enjoying emulators and cores for more than a decade and wanted to thank you for your contribution to the retro gaming scene!

luckyluca

@dankcushions

Regarding Roslof's doc, does the following mean that lr-mame core is using the mame non-merged romset version 0.222? does it also mean that the actual core version in Retropie must be 0.222?
Without causing controversy, I'm asking because 0.222 is a tricky romset one to source, let's just say that it's not too common.

Major testing is complete. Occasionally checking when new versions pop-up (lr-fbneo changes VERY rapidly, but... trying to keep up).
of emulators are updated. Note lr-mame tested with version lr-mame 0.222.

Also, regarding fbneo, from the retropie doc, I suppose that it uses FB Neo v0.2.97.44 and that it superseeds fbalpha2012 completely.
Regarding bios, neogeo and neogeo-cd aside, I suppose there are no bios zips required for fbneo arcade, or am I terribly wrong?

Thanks and happy Saturday!

dankcushions

@luckyluca said in Help batch running arcade games:

@dankcushions

Regarding Roslof's doc, does the following mean that lr-mame core is using the mame non-merged romset version 0.222? does it also mean that the actual core version in Retropie must be 0.222?
Without causing controversy, I'm asking because 0.222 is a tricky romset one to source, let's just say that it's not too common.

i don't maintain the doc so you'll have to ask roslof about that. that said, it's simple enough to find the current version of lr-mame on github: https://github.com/libretro/mame - looks like 0.230 currently, if you updated from source. lr-mame should track current mame, so it's constantly updated.

Also, regarding fbneo, from the retropie doc, I suppose that it uses FB Neo v0.2.97.44 and that it superseeds fbalpha2012 completely.

nope, it's 1.0.0.02 now. though, again, fbn's romset is a derivative of current MAME afaik, so it's constantly updated.

to this end it's fairly difficult to keep the various compatibility lists and doc pages up to date for current MAME and FBN. i removed all the compatibility lists from retropie's docs. i prefer to just refer people to their respective project pages.

Regarding bios, neogeo and neogeo-cd aside, I suppose there are no bios zips required for fbneo arcade, or am I terribly wrong?

fbn needs BIOS for other stuff also. see https://retropie.org.uk/docs/FinalBurn-Neo/ - a current dat will have the details

luckyluca

thanks a lot, I feel like Alice following the white rabbit in the hole.

I can imagine maintaining compatibility must be hell;
I assumed 0.297.44 was the right romset version, from the fbneo retropie docs, and thought that was aligned with the google sheet. I'll need to rethink my approach :-)

Edit: I found the other page listing 1.0 as correct for fbneo.

@dankcushions
So, am I right to assume that if I update the fbneo core, and then have the latest 1.0 full non-merged romset, all games contained would work aka there is no need for mame, unless a game is not included in the romset?

barbudreadmon

@dankcushions said in Help batch running arcade games:

nope, it's 1.0.0.02 now

Actually, current wip is 1.0.0.03 (odd numbers are wips, even numbers are releases)

dankcushions

@luckyluca said in Help batch running arcade games:

thanks a lot, I feel like Alice following the white rabbit in the hole.

I can imagine maintaining compatibility must be hell;
I assumed 0.297.44 was the right romset version, from the fbneo retropie docs, and thought that was aligned with the google sheet. I'll need to rethink my approach :-)

Edit: I found the other page listing 1.0 as correct for fbneo.

@dankcushions
So, am I right to assume that if I update the fbneo core, and then have the latest 1.0 full non-merged romset, all games contained would work aka there is no need for mame, unless a game is not included in the romset?

i am not sure about that - there may be occasions when the mame20xx version performs better, or the finalburneo version has emulation bugs or a crash or whatever, but generally, yeah.

barbudreadmon

@dankcushions said in Help batch running arcade games:

there may be occasions when the mame20xx version performs better, or the finalburneo version has emulation bugs or a crash or whatever

I'm not too worried about crashes, i have a batch script to detect those, but if you find an emulation bug please let me know.