Arcade overlays 4:3, 1600x1200
-
@svera Another question. I saw that you added artwork for the game Alcon. According to arcade-history.com, this game is known as Slap Fight (slapfigh.zip) outside of the U.S. β It's also part of my MAME collection under this name.
I fixed it quick and dirty on my cab by linking
cfgs/alcon.cfg
tocfgs/slapfigh.cfg
which gave Slap Fight the overlay, too, as it still contains the path toarcade-bezels/alcon.cfg
.But this raises the question how we should address such double-named games, as some people will build their romset based on U.S. titles and others will use the Japanese or international names.
Option 1: The png files aren't that big, so we could just make two file sets for each name. Option 2: We could choose an "original" and an "alternative" (or parent and clone), and create only a cfg file in
cfgs
that points to the original's cfg inarcade-bezels
. Option 3: We'll ignore any alternatives and leave it to the users to correct their cfg files accordingly.Both options 1+2 would be acceptible to me; what I wouldn't like so much is option 3 to just ignore any alternatives, which would require manual corrections for anyone who prefers them, and a general rule which versions should go into the repo.
What are your thoughts about this?
-
@clyde that's a good question. It may also happen that parent and clone bezels were actually different in real hardware; in that case it would be acceptable to treat those roms as different games.
In case that parent and clones share the same artwork, I would just create the.cfg
files for clones, pointing to a soft link of the parentPNG
. That soft link would be named as the clone rom name. This way, you avoid having duplicate images in the repo.Would that work for you?
-
@svera I concur that different cfg + png files are only necessary if the original artwork was different between regional versions of the cabinets.
However, I don't know how Github would handle symlinks, do you? (And/or across operating systems if we want to support that principally.) Instead, we could either use just a single cfg file in
cfgs
, or both cfgs there and inarcade-bezels
, pointing to the next file in line (cfg or png) of the original and avoid any potential incompatibilities of symlinks. Additionally, we could add a comment in the clone's cfg that explains this setup.So, my suggestion would be either
cfgs/clone.cfg
pointing toarcade-bezels/original.cfg
(no clone.cfg or clone.png there)
or
cfgs/clone.cfg
pointing toarcade-bezels/clone.cfg
pointing tooriginal.png
(no clone.png there)
If, however we could use symlinks with Github without any problems, I would happily agree to link any of the three files to their original's counterparts. π
-
@clyde Github stores the symlinks but you're right, they are not compatible with Windows systems from the get go. So, IMHO the most balanced option is the first one you pointed out, that is,
cfgs/clone.cfg
pointing toarcade-bezels/original.cfg
(no clone.cfg or clone.png there) -
@svera Deal. That leaves one question β¦ how do we define parent and clone? I see two reasonable options: either we follow MAME's definition of parent and clone, or we say that whichever version the creator of an overlay uploads to the repo is the parent no matter what MAME says.
The first option would be in line with many other tools who follow the MAME definitions, but the second may be more practical and would give the uploading person somewhat more weight and recognition. It may also require less rework, since we wouldn't have to change the uploaded files, but only add the "clone's" cfg file regardless what MAME says.
We actually have our first example: MAME 2003's xml file defines Alcon as a clone of Slap Fight, while we presently have Alcon as the "parent" in the repo. Option 1 would require to rename all three files to slapfigh.* and create a new alcon.cfg, while option 2 would keep the files like they are now, and add just a slapfigh.cfg.
So, it's coherence versus practicability. Frankly, I don't really care, so I would like to leave the decision to you as the repo's owner. π In return, I offer to make the necessary changes to the repo afterwards. π
-
@clyde Don't forget that parent/clone relation in mame ain't static over time/mame-version
-
@ashpool A valid point in principle, but does it happen frequently enough to be an issue? And since MAME 2003 is the standard arcade emulator for RetroPie, and fairly immutable as I understand it, since any additions were forked to Plus quite a time ago, we could just use its dat as our fairly immutable standard for those definitions.
Disclaimer: This isn't me arguing for this option, I'm still very undecided about that. π
As one of the contributors to the repo, do you have a preference?
edit: typo
-
@clyde actually is a little more complex than that. Following the Alcon / Slap Fight example, Alcon is the parent romset since MAME 0.138u3 as you can check at http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=alcon&arcade_only=0&autosearch=1. In the end this means that parent romsets may change over time. In this regard, I've been following whatever was set in MAME's latest version at bezel creation time.
For naming and parent/clone relationships, I would follow MAME conventions as you say, and use MAME latest version as reference.
-
@svera said in Arcade overlays 4:3, 1600x1200:
For naming and parent/clone relationships, I would follow MAME conventions as you say, and use MAME latest version as reference.
Fine with me, thanks for the link to look up the P/C data.
-
@clyde said in Arcade overlays 4:3, 1600x1200:
So, it's coherence versus practicability. Frankly, I don't really care, so I would like to leave the decision to you as the repo's owner. π In return, I offer to make the necessary changes to the repo afterwards. π
As promised: https://github.com/svera/vertical-bezels-4-3/pull/12
-
Announcement: Scramble coming up in 4-5 hours β¦
(In the case that you just decided to make one for it, too. π )
-
Question: Should I cut back the coloured arc at the lower left and/or the weapon at the right side, because they are too intruding, or is it okay like this? The original cabinet also had these protruding elements.
-
@clyde I also think these elements are too intrusive. I know they were also in the original cabinet, but I guess its display had a generous black bezel around so I don't think they were hiding game graphics. I vote for cutting them. BTW, great job!
-
@svera Okay like this? If so, I'll update my pull request accordingly. I cut the Weapon and the arc. The other protuding elements shouldn't hide any important graphics in my opinion. What do you think?
-
@clyde looks good to me!
-
(And yes, the original bezel has just mirrored images, too.)
-
@svera I updated my PR with the new Scramble images and Roc'n Rope. If both are okay, you can accept the PR. I'm not planning to add or change anything more today.
-
Next: Last Duel (half done)
-
@clyde Should do it... but for my own setup: Can you send me your source(s) for the 1st one?
Querying my usual suspects:
https://www.arcade-museum.com/game_detail.php?game_id=9447
-> https://flyers.arcade-museum.com/?page=flyer&db=videodb&id=944&image=2
and
http://adb.arcadeitalia.net/media/mame.current/artworks_previews/scramble.png?release=199I am inclined to say, personel I would srtrip the left/right borders so that the shoulder of the alien fighter on the right one is matching the displays borders and the gun should protrude (including a black bar between bezel and game screen) a bit into the screen.... Just personal taste, so if you can spare the sources, no need to change it in the repo ;)
-
@ashpool said in Arcade overlays 4:3, 1600x1200:
@clyde Can you send me your source(s) for the 1st one?
Done off-site.
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.