Arcade overlays 4:3, 1600x1200

Clyde

@svera Inspired by your review of my pull requests, I checked all of the other cfg files for 0.90000 opacity. Seems like many still have this value:

$ grep 0.9 cfg/*
1941.cfg:input_overlay_opacity = "0.900000"
1942.cfg:input_overlay_opacity = "0.900000"
1943.cfg:input_overlay_opacity = "0.900000"
19xx.cfg:input_overlay_opacity = "0.900000"
aerofgt.cfg:input_overlay_opacity = "0.900000"
arkanoid.cfg:input_overlay_opacity = "0.900000"
arknoid2.cfg:input_overlay_opacity = "0.900000"
batrideru.cfg:input_overlay_opacity = "0.900000"
btime.cfg:input_overlay_opacity = "0.900000"
btimem.cfg:input_overlay_opacity = "0.900000"
centiped.cfg:input_overlay_opacity = "0.900000"
commando.cfg:input_overlay_opacity = "0.900000"
congo.cfg:input_overlay_opacity = 0.900000
contra.cfg:input_overlay_opacity = "0.900000"
cosmogng.cfg:input_overlay_opacity = "0.900000"
ddonpach.cfg:input_overlay_opacity = "0.900000"
dimahoo.cfg:input_overlay_opacity = "0.900000"
dkong3.cfg:input_overlay_opacity = "0.900000"
dkong.cfg:input_overlay_opacity = "0.900000"
dkongjr.cfg:input_overlay_opacity = "0.900000"
esprade.cfg:input_overlay_opacity = "0.900000"
firetrap.cfg:input_overlay_opacity = "0.900000"
frogger.cfg:input_overlay_opacity = "0.900000"
guwange.cfg:input_overlay_opacity = "0.900000"
ikari.cfg:input_overlay_opacity = "0.900000"
kchamp.cfg:input_overlay_opacity = "0.900000"
mappy.cfg:input_overlay_opacity = "0.900000"
mercs.cfg:input_overlay_opacity = "0.900000"
mrdo.cfg:input_overlay_opacity = "0.900000"
mspacman.cfg:input_overlay_opacity = "0.900000"
pacman.cfg:input_overlay_opacity = "0.900000"
pengo.cfg:input_overlay_opacity = "0.900000"
qix.cfg:input_overlay_opacity = "0.900000"
timeplt.cfg:input_overlay_opacity = "0.900000"
tp84.cfg:input_overlay_opacity = "0.900000"
varth.cfg:input_overlay_opacity = "0.900000"
zaxxon.cfg:input_overlay_opacity = 0.900000

I could fix them with a quick sed one-liner. Shall I?

svera

@clyde go ahead!

Clyde

@svera Done!

Clyde

@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 to cfgs/slapfigh.cfg which gave Slap Fight the overlay, too, as it still contains the path to arcade-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 in arcade-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?

svera

@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 parent PNG. 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?

Clyde

@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 in arcade-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.cfgpointing to arcade-bezels/original.cfg (no clone.cfg or clone.png there)

or

cfgs/clone.cfgpointing to arcade-bezels/clone.cfg pointing to original.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. 😊

svera

@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 to arcade-bezels/original.cfg (no clone.cfg or clone.png there)

Clyde

@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. 🙂

Ashpool

@clyde Don't forget that parent/clone relation in mame ain't static over time/mame-version

Clyde

@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

svera

@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.

Clyde

@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

@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

Clyde

Announcement: Scramble coming up in 4-5 hours …

(In the case that you just decided to make one for it, too. 😉 )

Clyde

Scramble

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.

svera

@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!

Clyde

@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?

Scramble updated

svera

@clyde looks good to me!

Clyde

Roc'n Rope

Screenshot

(And yes, the original bezel has just mirrored images, too.)

Clyde

@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.