Arcade overlays 4:3, 1600x1200

svera

@Ashpool It was, I've already merged your pull request so your files are already available to everyone. Thank you very much for your contribution and keep it coming!

Ashpool

@svera Ok, will do.... step by step as my setup got configured/populated and I may have the desire for one ;)

At the moment my doings for overlays and populating my DIY-Cade Project got a little drawback: Because and just out of curiousity how the source XY of a given rom and its targeted DAR would fit a targeted max resolution, I've wrestled with my python-fu (barely existend) and UIs in Python (no former experience, always worked with it in a CLI only or (IDE based) Matlab Style of usecase before) and so, as the result of a long story, left to be untold here, this here came to be:

At least for me it has a working stage that will do, everything else I would expect that baby to do (or free it from further bugs I may encounter whilst using it) may remain in a >>will never be done, unless i really have the need (or spare time) for it<< state...

[EDIT:]
In the meantime, here is my overlay for burgertime (as the repo already has the primary rom title, I opted for the filenames to be a clone thereof: btimem)

[Don't want to start a alternate versions war here (IMHO-it is not a competition, but collaborated work), but that was one overlay where I wanted to have another (and more simple) variant for on my setup]...

Ashpool

And three more...

kangaroo:

I am inclined to remove the "berries'n'bell" accessoires and to go with apes'n'apples+roos alone... but as i haven't decided yet, the early version is presented here ;)

phoenix:

and ... vanguard:

Clyde

@Ashpool Wow, great work output. It shames me insofar that I didn't do any more overlays since May. I certainly plan to do so in the dark half of the year, although Minecraft has caught me in its grip once again at the moment. 😔 😇

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)