Nice MAME2003 overlays repository
-
@UDb23 I want to understand how the game console overlay config file works to implement it in the script.
Let me see if I understood well:
- the
ROM_Name.cfg
must be in the same dir as the ROM. - the
ROM_Name.cfg
file must be named exactly the same as the ROM file name, except the trailing.cfg
. - configs in
ROM_Name.cfg
overrides the configs on system specificretroarch.cfg
.
Can you confirm if the sentences aboce are true?
- the
-
@meleu said in Nice MAME2003 overlays repository:
the ROM_Name.cfg must be in the same dir as the ROM.
yesthe ROM_Name.cfg file must be named exactly the same as the ROM file name, except the trailing .cfg.
yes, including extension (like gwa4.gba.cfg in the picture below)configs in ROM_Name.cfg overrides the configs on system specific retroarch.cfg.
yes.; please note that both cfg's for each rom override settings in retroarch.cfg for that specific system (just for the specific rom)To summarize setup for consoles:
ROM specific overlay setup:
- ROM_Name.cfg (with naming and folder as mentioned before)
- ROM_Name_system.cfg (to be placed in overlay folder; as gwg4_gba.cfg in the example below, with the overlay png) ("system"=3 letters.)
SYSTEM generic overlay setup:
system-LR.cfg content must be added (placed above the #include line) to existing retroarch.cfg in the configs system (e.g. gba-LR.cfg) folder. ("system" = 3 letters)
If no retroarch.cfg exists in that folder (was the case for me for gba), just copy the provided retroarch.cfg into that folder (no edit required).system_artist-ovl.cfg must be placed in the overlay folder (with the overlay png)
Hope this helps. If anything unclear just let me know.
-
@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 theinput_overlay
entry. This file will be the one that must be in the roms dir. -
@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 folderAs 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... -
@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!
<extension>zip</extension>
-
@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 ;-)
-
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!
-
@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! -
@meleu OK, agreed.
So this also means "Option X" subfolders will have their own info.txt; correct ? -
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"
-
@meleu Makes sense. One file does it all.
-
-
@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. -
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!
-
@backstander You would also have to have a database or huge file list of what each game's hash should be to match.
-
@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. -
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 withROM.xxx
and if it isn't, then do the checks you mentioned above.@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)
-
@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 thegame_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. :-)
- exact match with
-
@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. -
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 ;-)
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.