Nice MAME2003 overlays repository

meleu

@UDb23 Starting today I think I will have two intense weeks. So I can only implement the console overlays installation later. But I'm predicting some issues with the filenames here.

With the arcade overlays it was pretty simple because we are sure that the ROM files end with .zip, therefore the ROM config is .zip.cfg. But it's not true for the other systems.

I'm starting to think in a better solution to make the script identify which file is what: using the file content rather than filenames.

I don't know the details of those options/configs in those files, but as far as I understood the file that must be in the roms directory always has an input_overlay entry, and this entry is not present in that file that must be in .../overlays/arcade-bezels/ directory.

Can you confirm that?

If yes, I think that a better approach is to make the script look the .cfg files searching for the input_overlay entry. This file will be the one that must be in the roms dir.

UDb23

@meleu if your script can check the content of the file I can add a specific comment line in each cfg file. I think this is the easiest way to make sure your script can identify the cfg file.

E.g. first line in cfg
#meleuscript: overlay -> cfg to be placed in overlay folder
#meleuscript:rom -> cfg to be placed in ROM folder

As we're thinking about this: while arcade roms have specific and unique ROM filenames, my understanding is that console ROM filenames for the same game could be different ( different extension, different name).
So it's user responsibility to check and be sure his roms use same ROM naming as the script...

backstander

@meleu I also think there could be an "information file" (maybe an xml file?) that is in the same directory as the overlay that has the information needed like the file's extension and if there is clones and what their names are and any other information needed like screen positioning for the generic GBA overlay, etc.

You guys will need to come up with what the variables will be but it's an idea!

UDb23

@backstander Right, that's another option. I also proposed this approach when we started this project; not sure it's better. It's @meleu's decision now ;-)

meleu

OK guys. This brainstorm was good. I am very strict in adhering to the KISS principle, so no xml files for a such a simple task, please! :)

But you guys gave me an idea. Here's my proposal:

Every single overlay directory must have a file named info.txt with the following content (example for Aliens):

# yes, we can have comments here
rom_config = "aliens.zip.cfg"
overlay_config = "aliens.cfg"
# multiple values separated by semicolon
overlay_image = "aliens_udb_1-ovl.png; aliens_udb_2.png"
rom_clones = "aliensa; aliensj; aliensu"

Many problems will be solved if we start using such a file!

UDb23

@meleu said in Nice MAME2003 overlays repository:

Well, I was holding back myself from asking you to do an overlay for Cadillacs and Dinosaurs. :-)
It's one of the most played by kids (and grownups too) when visiting my home.

Here it is:

Cadillacs and Dinosaurs overlay now available in the Repo.

Took a while to find, select and edit the right images.. these graphics are so great.
Never seen any Mark Schultz artwork before; thanks for making me discover all this!

UDb23

@meleu OK, agreed.
So this also means "Option X" subfolders will have their own info.txt; correct ?

meleu

@UDb23

So this also means "Option X" subfolders will have their own info.txt; correct ?

I think it's better to use only one info.txt for each game. If we stick with the info.txt approach, all the rules we defined become guidelines. The final word will be in the info.txt file. Therefore we don't need a subfolder for the optional config files. It could be, for example, RomName_opt1.zip.cfg (actually the name pattern will be completely irrelevant to the script, since it will get the info from the info.txt file).

I'll try to write the rules for the info.txt and submit to the repo. But here is an example for the Burning Force (the game that has more art in the repository).

rom_config = "burnforc.zip.cfg"
overlay_config = "burnforc.cfg"
overlay_image = "burnforc_udb-ovl.png"
rom_clones = "burnforco"
launching_image = "burnforc-launching.png"
scrape_image = "burnforc-image.png"
rom_config_1 = "Option 1/burnforc.zip.cfg"
overlay_config_1 = "Option 1/burnforc.cfg"

UDb23

@meleu Makes sense. One file does it all.

meleu

@UDb23 take a look at my latest PR. ;-)

info.txt rules here.

UDb23

@meleu Well done, thanks.
I think I'll create some vba code (own use) for my rom resolution db so that it generates cfg files and info.txt automatically; will speed up overlay creation process.

backstander

Another challenge for @meleu's script is that the non arcade ROM filenames are not static like the MAME/FBA/Arcade ROM filenames. For example: @UDb23's Game & Watch Gallery 4 overlay for GBA assumes that the ROM is named "gwg4.gba" but like on my system, that ROM is named "Game & Watch Gallery 4 (USA).zip" and there could be a million variations to the name of this one ROM.

I know I can just easily rename it with mv gwg4.gba.cfg Game\ \&\ Watch\ Gallery\ 4\ \(USA\).zip.cfg but the whole reason to use this script is to make this process much easier and also for the Linux noobs that don't have a clue about manually renaming files.

One solution could be comparing hashes/CRC/MD5 but this might open a new can of warms. Also since RetroArch now supports 7zip, if we compare hashes, then the script would also need to look inside of Zip's and 7zip's to calculate the hashes for every ROM/file in that directory.

Just some food for thought!

HurricaneFan

@backstander You would also have to have a database or huge file list of what each game's hash should be to match.

meleu

@backstander I thought about it. The script will use game_name from info.txt to try to find the rom name (file system itself and gamelist.xml) and let the user choose in a list of probable options.

backstander

@meleu

The script will use game_name from info.txt to try to find the rom name (file system itself and gamelist.xml) and let the user choose in a list of probable options.

If the ROM is scraped and in the gamelist.xml that might be a really good way to find a match. I can see this way working for "Game & Watch Gallery 4 (USA).zip" but maybe not so well for un-scraped "gwg4.gba". Maybe add a small first check to see if the ROM.xxx.cfg filename is an exact match with ROM.xxx and if it isn't, then do the checks you mentioned above.

@HurricaneFan

@backstander You would also have to have a database or huge file list of what each game's hash should be to match.

Well, we would only need to do this with non-arcade ROMs and would just need to find all the acceptable/known hashes for that one game and put them in the info.txt like this:

rom_hash = "64565415624615241652126; 79495795464654; 54654654"

(note: those are made up hashes)

meleu

@backstander OK. The script will use 3 methods:

exact match with rom_config from info.txt (without the trailing .cfg).
try to find something using the game_name from info.txt.
try to find something in gamelist.xml using the game_name from info.txt.

But using hashes is a severe agression on the KISS principle. :-)

UDb23

@meleu Yes, we should keep this absolutely simple. I would suggest to avoid hashes. Complexity to manage would be too big for the scope.
The script, getting the name from the info.txt, could simply tell the user what is the required rom name and suggest manual renaming. ROM folders are accessible thru Samba shares so even a beginner user can access and rename.

backstander

When it comes time to make a Wiki/Docs page about this script, we'll have to remember to put something about the names have to match in the troubleshooting section ;-)

UDb23

@backstander Good suggestion; yes this should be underlined.
With @meleu's proposed 3 methods I hope we'll be able to automatically match rom names in most cases.

meleu

@backstander I was reading a book today and faced a quote from Ralph Waldo Emerson that made me remember our brainstorm here:

We ascribe beauty to that which is simple; which has no superfluous parts; which exactly answers its end(...)

Cheers! :)