Backdrops in mame2003-plus

Riverstorm

@Clyde - Ok, basically it sounds like @UDb23 was correct with his initial hunch of why were seeing 1600x1200. Normally Fullscreen Width and Height are commented out in the global config so I can't explain why those fields were filled in with those specific values just by saving as they are just a comment. I do Save Current Configuration all the time also but RA doesn't write any new values for me. I don't know but I would assume they came from the tvservice hanshake maybe?

I don't think RA makes any assumption on the correct resolution to use. I would think it needs to be detected on the HDMI cable handshake or manually set in your config.txt. In my test with those values commented out and booting with no HDMI cable I get "garbage" once I plug the cable back into my Pi. Basically it's not displaying fully correct. Either way I think we know what is happening when we see 1600x1200 in RA now so I digress. ;)

The only issue I see with that is if you move your Pi to different displays then it will display incorrectly because it's been "locked" to 1600x1200 in RA but in a custom cab it makes no difference.

I would still contend those values are safe and genuine values to use for overlays. The take away for me from this conversation is there's two ways those values reflect correctly and will allow overlays to work properly. Maybe we'll discover more later.

One is leave everything at it's defaults and when you plug your Pi into a TV or monitor the values displayed in RA are correctly.

Two you showed us by inserting the correct full screen display values into Fullscreen Width and Height will also work for overlays but display the monitors native resolution.

I suppose you could say that someone is adding completely arbitrary random values at the RA global, system and/or core configs for aspect ratio and they might be incorrect but then again you may add wrong values to any RA setting and say don't trust what your seeing.

I use about 225 custom portals and they display perfectly, even some with integer scaling. When I start my Pi on my monitor which is 1920x1200 (vs an HD TV) I get overlay overlap between all games and overlays. Also it comes up a few centimeters to short on the y value but the x value is correct since both are 1920 wide, it centers correctly. So basically it's centered correctly on the x but short on the y due to the custom portal being set for HD. Then if @UDb23 adds an overlay I delete the custom portal and let Core Provided do the work in setting the correct resolution so the artwork displays correctly down to the pixel.

When you asked about where I got those values way up top in this thread about the backdrop positioning in relation to the game resolution you only need to know two things really. The displays resolution and what game. With a piece of paper or calculator you can manually calculate the 5 or 6 values RA Core Provided will display pretty easy.

Anyway I know I get windy and I appreciate you sharing all the information as it helps me to better understand different aspects and different ways people use their Pi and how they set it up etc. as I am always looking for better ways to do things. If you come across a good step by step of what's happening with any of things discussed I would be grateful if you post a link as I love to read and I would do the same.

I know when I first started I had trouble wrapping my head around setting values between global, system, core and ROM and the inheritance hierarchy relationship. Also when it came to inputs it was the same challenge but you had to add another layer to all that, direct input. Now I use every level of RA with custom settings and do most changes from the command line.

@UDb23 - Thanks for the new overlay it looks great and I look forward to testing it. We have been below freezing (32F/0C) forever now. I'll let you know if we ever see water vs ice again. ;)

UDb23

@Clyde said in Backdrops in mame2003-plus:

Is this valid for both binary updates and those from source?

I think both. That introduces an issue, already mentioned by @Riverstorm , that if you have customized BDs they will be overwritten if you update.

Clyde

@UDb23 Good to know. Would write protecting them help? Since Retropie's update script runs with root permissions, I don't know if it will just ignore the (missing) permissions.

Having some sort of file hierarchy like the one for RetroArch config files would be nice.

UDb23

@Riverstorm said in Backdrops in mame2003-plus:

We have been below freezing (32F/0C) forever now. I'll let you know if we ever see water vs ice again. ;)

Hope you'll finally get back to acceptable temperatures !
I suppose you got a lot of snow so, at least, people could enjoy skiing (at reasonable temps).

UDb23

@Clyde Agree.
As you may have seen I asked @meleu if he could add BD functionality to his script.
Mame2003plus only allows one specific BD per ROM, while with the script user could choose from multiple options and also have backup/restore function for BDs.
In that way we could manage our BDs regardless of what the core install script does.

Clyde

@UDb23 said in Backdrops in mame2003-plus:

Mame2003plus only allows one specific BD per ROM, while with the script user could choose from multiple options and also have backup/restore function for BDs.

But that would mean the user has to backup the BDs before any core update and restore them afterwards? Just checking if I'm understanding you completely.

If it is so, a way with just another BD location that overrides the standard BDs would be better. But beggars can't be choosers … for any feature wanted there has to be someone who implements it in his or her freetime.

Including it in @meleu's script would be very useful and fitting, although I myself do such things manually most of the time anyway – „because I can“, to have full control, and to maybe learn something new along the way. 😊

But enough for now. Off to work. 🦸I'll test if the update script will overwrite write protected files at the next opportunity.

Clyde

Just as I was about to leave, mame2003-plus finished compiling (took about 30 minutes). Alas, my write protected omegrace.zip backdrop file has been overwritten. Ironically, it's still write protected. So, that is no way to protect custom backdrops from updates. 😛

UDb23

@Clyde said in Backdrops in mame2003-plus:

If it is so, a way with just another BD location that overrides the standard BDs would be better.

That's exactly the concept and, of course, I'd do it manually too.. .but may users do not want (or are not able) to mess around with command line / mc ;-)

Clyde

@UDb23 When it comes to backups, most users don't do them regularly if at all, even on operating systems they are (kinda) used to. Until the worst case happens and they cry for help to rescue their important data.

But as two sayings go, a) data without backups isn't important by definition, and b) no backup, no mercy. 😛 Although I have to admit that I still sympathise with people who lose their data by their own negligence.

That said, in the case of Retropie it certainly helps being a Linux user with a) already some knowledge about this system and b) full access to RP's file systems on my PC if necessary.

UDb23

Gorf (1080p) backdrop WITH LAMPS now ready.

Good news: lamps work fine. Image proportions are correct.
Bad news: resolution is quite bad!

I'm getting frustrated on this; all the work on high res images and then ... bad quality output.
:-(

@grant2258 I even tried adding a "fake" 1080p transparent backdrop (wider as the game area) to force mame to spit out a higher res, as you suggested, but it seems to have no effect. It is still included in the zip file (referenced as sethd.png in the .art file).

@Riverstorm @grant2258 could you have a look at this ? Any ideas ?

In the specific case of Gorf I think I can find a workaround (bezel made as RA overlay and just the lamps "artwork" managed by mame backdrop system) but I really would like to find a method to get acceptable res in the BD system itself.

quicksilver

@UDb23 I cant wait to test this out. Sounds awesome! Though maybe I will wait until you are satisfied with it.

UDb23

@quicksilver Please try it and let us know how's resolution in your case.

UDb23

BTW it seems to me that both mame2003 and plus emulation (on the a Pi3 B+) of Gorf is slower than the real thing. Take a look at this video and in particular at the speed of your shots.

Do you see/feel the same ?

grant2258

set your artwor res x2

UDb23

@grant2258 Already tried... no visible impact on artwork. Test done on my Pi3 B+.
My version of mame2003plus is not the latest; did anything art related changed in the last month (apart the new vector res settings) ?

grant2258

nah nothing changed in the artwork looks fine her on my laptop at artwork res x2 look pretty bad at x1 will test on the pi when i have time. I did notice on the pi i had to edit my global config file to set teh artwork res doesnt set with game over ride for some reason

quicksilver

@UDb23 I tried to install Gorf overlay via the rpie-art script but it says there is a problem

grant2258

its look fine with bi linear filtering on or a shader on considering is has to scale to the res set in ra this is to be expected. Do you know the res the core is outputing
484 x 320 for x1

Clyde

@quicksilver What was the exact error message?

quicksilver

@Clyde not by my pi right now, but something to the effect of "there was an issue with the gorf overlay" contact UDb23 on the github issue tracker"

This happened with several other of his overlays and he was able to fix them for me in the past.