Arcade overlays 4:3, 1600x1200

svera

@Ashpool lovely, bezels merged. Don't stop! 😉

svera

Added Cosmo Gang overlay to the repo.

Ashpool

@svera brilliant, haven't known about that one... and i really enjoy/adore that gorf/phoenix/galaxian/etc. kind of gameplay ;)

In addition, i worked on a childhood memories I wanted to have done, before going on with the general configuration and specific system/game settings for my "DIY Arcade" (Ok, there are still a few games left, I may do inbetween):

:Karate Champ:

Just going with the original Bezel, would have been nice and easy, but I wanted to have the "RTFM" for the Joysticks on Screen... and so, to get a somewhat symmetric overlay, I also includes the general instructions. ... Though I downsized the critical elements for the 1600x1200 and 1024x768 overlays from "source" (and not Source->1600->1024), I fear that the instructions for the moves ain't readable in the 1024 Variant :/

Edit:
P.S.: Seeing the Moiré pattern in the screenshot - well, there is some config work to be done ;^>

svera

Added Arkanoid 2 bezel to the repo.
@Ashpool regarding your moiré pattern problem, have you tried zfast vertical shader? I haven't had any moiré issues with that shader.

Ashpool

@svera Thanks! For fast access & screenshots(most of the times) I was using the first crt-shader from the presets, the zfast ones (so far) eliminated the moiré :up:

And though I wanted to have another set of bezels to upload, thanks to circumstances and the "I am not a beer"-Virus at hand, and whatsnotandsoforth, etc. ... I am at the moment bussy in setting up a PC with an (formerly win7 offline gaming)/(now to be added)ubuntu(20LTS) dual-boot for my daugther to be prepared for "home-schooling" times (and I bet that they will come!)... whence I am done with that, I may be able to supply further overlays ;)

Clyde

@Ashpool I can also recommend the zfast shaders for their speed. They seem to be significantly faster than the crt-pi-* ones.

Ashpool

Added Bagman (From Sideart/Marque - the real Arcade Bezel was just a black/blank overlay)

After I've spend some time on Popeye, just to realize later that it is a 4:3 game... sigh... (and that where I am now parsing/merging Catlist&Mame.xml infos for my little python app, and should have known better if I would actually use it, instead of just scripting it&its companions).... so here is my 1600x1200 bezel for popeye... I'll be keeping that in my archives, because it may be a good base to get a 1080/16:9 overlay alternative for the present ones :/ (still wasted hours :p) :

Clyde

Finally, I got around to make another overlay! 😄

Lady Bug

Lady Bug

Update: Moved the flower more into view.

Clyde

Next: Circus Charly

Circus Charlie

This took approx. 2-3 times the time to make as Lady Bug, since I had to reconstruct it from scratch using the individual parts from @nono6493's 16:9 overlay except for the monkey which I took from arcadeartwork.org.

Update: Added half a monkey on each side. 😉

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.