• Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
RetroPie forum home
  • Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login

Arcade overlays 4:3, 1600x1200

Scheduled Pinned Locked Moved Projects and Themes
overlaysbezels1600x1200
104 Posts 14 Posters 39.4k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C
    Clyde @Ashpool
    last edited by 21 Oct 2020, 11:15

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

    1 Reply Last reply Reply Quote 0
    • A
      Ashpool
      last edited by Ashpool 21 Oct 2020, 23:48

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

      bagman.jpg

      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) :
      popeye.png

      1 Reply Last reply Reply Quote 2
      • C
        Clyde
        last edited by Clyde 6 Jun 2021, 14:08 31 May 2021, 22:08

        Finally, I got around to make another overlay! 😄

        Lady Bug

        Lady Bug

        Update: Moved the flower more into view.

        1 Reply Last reply Reply Quote 4
        • C
          Clyde
          last edited by Clyde 6 Jun 2021, 16:21 6 Jun 2021, 12:33

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

          1 Reply Last reply Reply Quote 1
          • C
            Clyde
            last edited by 6 Jun 2021, 15:56

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

            S 1 Reply Last reply 6 Jun 2021, 17:48 Reply Quote 0
            • S
              svera @Clyde
              last edited by 6 Jun 2021, 17:48

              @clyde go ahead!

              1 Reply Last reply Reply Quote 0
              • C
                Clyde
                last edited by 6 Jun 2021, 18:56

                @svera Done!

                1 Reply Last reply Reply Quote 0
                • C
                  Clyde
                  last edited by Clyde 6 Jun 2021, 20:59 6 Jun 2021, 19:57

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

                  S 1 Reply Last reply 6 Jun 2021, 21:56 Reply Quote 0
                  • S
                    svera @Clyde
                    last edited by 6 Jun 2021, 21:56

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

                    C 1 Reply Last reply 7 Jun 2021, 12:03 Reply Quote 0
                    • C
                      Clyde @svera
                      last edited by Clyde 6 Jul 2021, 13:04 7 Jun 2021, 12:03

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

                      S 1 Reply Last reply 7 Jun 2021, 12:50 Reply Quote 0
                      • S
                        svera @Clyde
                        last edited by 7 Jun 2021, 12:50

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

                        C 1 Reply Last reply 7 Jun 2021, 19:54 Reply Quote 0
                        • C
                          Clyde @svera
                          last edited by 7 Jun 2021, 19:54

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

                          A S C 3 Replies Last reply 7 Jun 2021, 20:18 Reply Quote 0
                          • A
                            Ashpool @Clyde
                            last edited by 7 Jun 2021, 20:18

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

                            C 1 Reply Last reply 8 Jun 2021, 04:59 Reply Quote 0
                            • C
                              Clyde @Ashpool
                              last edited by Clyde 6 Aug 2021, 12:58 8 Jun 2021, 04:59

                              @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

                              1 Reply Last reply Reply Quote 0
                              • S
                                svera @Clyde
                                last edited by svera 6 Aug 2021, 07:21 8 Jun 2021, 06:20

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

                                1 Reply Last reply Reply Quote 0
                                • C
                                  Clyde
                                  last edited by 8 Jun 2021, 14:15

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

                                  1 Reply Last reply Reply Quote 0
                                  • C
                                    Clyde @Clyde
                                    last edited by 8 Jun 2021, 22:27

                                    @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

                                    1 Reply Last reply Reply Quote 0
                                    • C
                                      Clyde
                                      last edited by 12 Jun 2021, 17:05

                                      Announcement: Scramble coming up in 4-5 hours …

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

                                      1 Reply Last reply Reply Quote 0
                                      • C
                                        Clyde
                                        last edited by 12 Jun 2021, 22:53

                                        Scramble

                                        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.

                                        S 1 Reply Last reply 13 Jun 2021, 07:43 Reply Quote 0
                                        • S
                                          svera @Clyde
                                          last edited by 13 Jun 2021, 07:43

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

                                          C 1 Reply Last reply 13 Jun 2021, 15:51 Reply Quote 0
                                          • First post
                                            Last post

                                          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.

                                            [[user:consent.lead]]
                                            [[user:consent.not_received]]