Mame 0.78 database for MAME 2003 - FB Alpha updated to v0.2.97.38 - New Game and Watch database

[lollo78]

No description provided.

[RobLoach]

Looks like a lot of removals:

+24,504 −208,398

You sure this is right?

[lollo78]

Yes! If you want done also your check/test.

For FBA the reason is described also in PR comment. From now, the only FBA Complete Collection v0.2.97.38 available on the Web merge clones into parents. So, instead of a splitted romset of 4771 roms, we have only 1454 roms.

For MAME, the only 0.78 full romset available is on TPB and it includes 4718 .zip file (about 15 BIOS file). But of course it contains also not working, majhong and other crap. I included all the file inside the database (like for FBA) - but not the BIOS - to respect the full romset (but, for personal use, I cleaned my romset at 1990 file :D).
I decided for mame2003 (mame 0.78) because is the only mame core that works on all the platform (also on Rpi). If it's not an issue for you, please add it to the origin master. The actual MAME.dat (without CRC) doesn't work (always empty playlist). So, why don't overwrite it?

In Retroarch I scanned both romset and I created the two playlists without issues (there are all the games inside and there aren't conflict from MAME and FBA .lpl).

[inactive123]

Don't overwrite the main MAME database like this. Instead, make a separate database DAT file and rdb for MAME 2003.

[lollo78]

ok, I'll push it as soon as possible

[lollo78]

@twinaphex
Done!
I also made a PR for the info file
libretro/libretro-super#289

[markwkidd]

Hi @lollo78 sorry I lost track of this thread and only just now found it. The new database does not work with a Non-Merged set (several reports about this in the forum as well.)

I opened an issue about Non-Merged sets in response: #248

[barbudreadmon]

What are the advantages of non-merged sets ? I mean, except being a lot more lazy (finding parent of your clone sure is a lot of work...). On the other side split sets help to save disk space, which is a good thing overall, and is needed on embedded if you want a full set.

[markwkidd]

From my perspective I would say it this way: all of the console systems
supported by the RetroArch database are Non-Merged. Learning what the
different kinds of Arcade sets even mean has been full of confusion for the
libretro development team (I could create a list of issues, pull requests,
and forum threads where this mild confusion is on display)

Even with better docs, split sets are unintuitive. Plus, the size
difference between a complete (including CHDs) Non-Merged MAME 0.139 set
and a complete split set is only ~25%. I would bet its similar for the
other MAME cores in libretro.

The questions: What kind of technical proficiency is RetroArch shooting for
in terms of its users? Once you know that:is the 25% space savings enough
of a tradeoff for making this much more complicated to the end user.

Another way to ask this is, would RetroArch want to start using Merged sets
for its console systems? That is technically possible, and I would go so
far as to say it wouldn't be hard to switch to that with the tools already
in place. In a world where non-merged sets are available.

[barbudreadmon]

Console systems are non-merged sets because, unlike arcade systems, there is no purpose in having split sets for 99% of them.

25% space saving is a lot on sd card / ssd.

I know a few end users and none of them ever had an issue with current split sets (and i'm talking about people not especially accustomed to computers).

I can't share your perspective.

[markwkidd]

I was saying that we could theoretically save a lot of space by moving to Merged sets for consoles. (Split doesn't really make sense, I agree).

Overall though it does seem like we must agree to disagree about arcade sets. :) I enjoy the conversation though!