Backdrops in mame2003-plus

UDb23

Battlezone "UV" ready:
alt text

I got quite crazy due to a bug in inkscape that was generating transparent areas; took me a couple of hours to fix !
Available in the Repo.

UDb23

@meleu said in Backdrops in mame2003-plus:

post what you have in mind on the rpie-art issue tracker: https://github.com/meleu/rpie-art/issues

Added detailed feature request, as an issue, to install backdrops.
Thanks pal ! And of course: no hurry.

ward614

Hello!

How should I go about installing backdrops to mame2003plus? Should I be using rpie-ovl, or is there a specific file I could add into the artwork folder?

Thank you!

UDb23

Backdrops are installed by the core itself (by updating ).
Or you can find zip files in the repo and copy them manually in the bios/mame2003plus/artwork folder.
Note: battlezone can be installed as an overlay (with the art install script).

ward614

@UDb23 That's actually fantastic! Thank you for letting me know!

Clyde

Hi @Riverstorm, I concur on most parts of your last post, so I'll only address some minor differences:

@Riverstorm said in Backdrops in mame2003-plus:

I do think we are mis-communicating with different terms and but nothing serious. Like when you use framebuffer I think of a certain amount of reserved RAM for a picture to be displayed but also maybe in the RAM it does have the desktop resolution. For me I wouldn't use those terms interchangeably.

Normally, I wouldn't either. It's just that RA in XMB mode says that a Fullscreen Width and Height of zero will use the "desktop resolution". But without a desktop, which resolution does RA use, then? My main suspect is the framebuffer, nothing more. And it's not really important for practical purposes, but mainly born from my own curiosity.

I think to get those settings stored you must be altering video options? I make changes and save my configs frequently but none of the settings I have changed alter the native resolution like what yours is doing. I have never tried from within Emulationstation as I am always in a game when I save my options.

In my tests, I didn't alter any settings. I just deleted the two lines for Custom Aspect Ratio Width and Height from the general retroarch.cfg, then I started Emulation Station > Retropie > Retroarch, only looked at Settings > Video to check the automatic values, and then saved the configuration via Main Menu > Configurations > Save Current Configuration. This saved the current (automatic) values for Custom Aspect Ratio Width and Heightin the general retroarch.cfg. The same happened from within an arcade game with the arcade/retroarch.cfg.

I do think the numbers are accurate. When I run on my TV the game resolution is 810x1080, when I turn on TATE mode it's 1440x1080. When I run on my monitor which has a native resolution of 1920x1200 the game resolution is 900x1200 when I turn on TATE mode it's 1600x1200. All these modes screenshots are the correct size as displayed in RA. Without this consistency @UDb23 just couldn't make his overlays. It's essential to the process.

If you're referring to tmy last point, it wasn't about the accuracy of the values, but rather that you can't be sure if those values represent the current game's resolution and are not just read from your/another's retroarch config. I just wanted to advice caution about this since you and @UDb23 seemed to take my values as genuine too quickly, when they actually were just stored at sometime before.

@UDb23 said in Backdrops in mame2003-plus:

Backdrops are installed by the core itself (by updating ).

I didn't know that. Is this valid for both binary updates and those from source?

grant2258

@clyde you are correct the custom aspect ratio can be set at any point in config files. In linux and windows you can view statistics to get the viewport that RA is using(you cant get these stats on on retropie). Ra will basically use the frambuffer that is set for the sdl port(im assuming the pi is using sdl for the display driver would need to really check). Result is the same either way the pi does not display these statistics.

when you take a screenshot with gpu screenshot on this is the resolution RA is scaling up or down too ie your framebuffer.

when you take screenshot with gpu screenshot off this is the resolution that particular core is outputting you ll notice raster (aka bitmap games) have a low res that why people need to use shaders ect when the image gets upscaled.

UDb23

Wasn't happy with my Gorf draft overlay so I reworked it quite a lot. Final overlay here.
Next step create specific .art to activate the lamps.

Clyde

@grant2258 Thanks for the information!

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.