Backdrops in mame2003-plus

grant2258

@clyde ill try clear up some confusion here gorf in reality is 4:3 the monitor is just rotated in the arcade. If you put tate mode on you will see it rotates properly at 4:3.

since we arent using the monitor rotated (tate mode) the image get sqashed to 3:4 and the original game resolution is upscaled too your 1600 x 1200 resolution at 3:4 . On a 1080p it would get upscaled to that res at 3:4 with core provided as well.

vectors well they are a little different mame lets you scale them that why you should pick your resolution you are using and thats why i added 1600x1200 you so that way no scaling is needed and its only done once in mame. If you are on 1600x1200 in ra and pick 1080p in mame.... mame will scale the image to 1080p then retroarch will scale that to 1600x1200 at this point your scaling two times.

Clyde

@grant2258 Thanks for the additional clarifications.

@Riverstorm I think I know now where we (you, me, and @UDb23) misunderstood each other, and I did some testing to verify my assumptions. I'll put the main points in a list for better reference:

I already tried to separate game resolution from screen resolution in my previous posts, like you suggested in your last post. So, we should be on the same page with that.
I only mentioned the frame buffer as a substitute for a desktop because the description of Fullscreen Width and Heightin the XMB interface says that RA will use the "desktop resolution" if they values are set to zero. Since the standard Retropie (which I do use) doesn't have a desktop, I suspect RA will use the framebuffer resolution instead. And without any manual tinkering, the frame buffer will follow the screen resolution that RP detects when booting.
With "rendering" I meant the whole process of displaying the final picture (i.e. game area plus the black borders), while I suspect that you meant only the creation and updating of the game screen area. This in mind and being no programmer myself, I strongly suspect that RA still "renders" (i.e. displays) the whole screen resolution regardless of the game resolution. It may "render" (i.e. update) only the game area to save resources like you suspected, though.
Apart from a possible misunderstanding, I still do not think that most monitors will display a raw 900x1200 image, at least not as a digital HDMI signal. For example, my 1600x1200 TFT and my 1280x720 video projector can't display each other's native resolution when I split my Pi's HDMI signal to both of them. So finally, I had to run the HDMI signal through a VGA converter on its way to the projector.
Furthermore, I don't think the Pi even allows for a 900x1200 display mode. You can see all supported modes here and list those that RP got reported by your monitor with the commands tvservice -m CEA and tvservice -m DMT.
For these reasons, I still don't believe that RA will output just the game resolution, even if it uses it for its internal screenshot function. But again, this may be just a misunderstanding because of our different use of "rendering". I meant that even with a game resolution of 900x1200, I think that RA will still send a 1600x1200 picture to the monitor, or whatever resolution your frame buffer has. (Maybe @grant2258 can confirm or deny this assumption of mine.)
My tests may have shown why my values for Custom Aspect Ratio Width and Height are different than yours and @UDb23's, as well as the game resolution. As @UDb23 suspected, they are stored in my …/configs/all/retroarch.cfg, but I don't remember putting them there. After I removed them, RA finally showed the game resolution as 900x1200 and an X position of 350 … in Gorf. In the overall Retroarch configuration without any core loaded, e.g. by starting RA from Emulation Station > Retropie > Retroarch, the automatic values are 1600, 1200, and 0.
Now for the storing part: If I save the current configuration without any core loaded, the above values of 1600/1200/0 will be saved in …/configs/all/retroarch.cfg. If I save from within Gorf instead, RA will save its values of 900/1200/350 in …/configs/arcade/retroarch.cfg. This may be how my values got saved without me noticing.
In conclusion (and again, if I don't misunderstand you), you and @UDb23 shouldn't see those values in the RGUI or XMB as reliable information about the game resolution. They may be just stored values from either general RA or another game of the same core, and they aren't even used if the Aspect Ratio is set to anything other than "Custom".

I hope I could get my thoughts across while emphasising that they aren't meant as absolute certainty or truth. 😉 😇

Riverstorm

@Clyde - I don't think your thoughts come across as absolute certainty at all. If either one of us knew the exact steps I think we would just outline them for the other. :) It's a great learning opportunity for me. I learn so much from these types of discussions.

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. There's a whole Wiki and many many articles for just the word framebuffer alone and it's benefits and shortcomings.

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.

Also definitely you can not display a 900x1200 on two displays with different native resolutions as tvservice is counting on the handshake to determine the native resolution. What I was trying to point out is that 900x1200 may be used on monitors with different native resolutions such as 1920x1200 and 1600x1200 will both use 900x1200 as the game resolution. I suppose custom portals are also an option to altering the game resolution.

If you turn off Screenshot GPU Enable you'll see the actual frame rendered in it's native resolution. It's very very small and rotated so it is 4:3. This might help seeing a visual. From there it's upscaled with techniques like nearest neighbor and rotated to the Core Provided resolution. Upscaling requires minimal processing power vs native resolution rendering. It's very easy on the Pi resources. I don't think you would gain much rendering at native resolution on these old games. Then finally overlays, filters, shaders, etc. are applied.

That's what you see with Screenshot GPU Enable ON. The completed frame ready to be output to the display. Maybe it's "padded" to the full native resolution after this step.

When you use TATE mode you only need to invert the X/Y values and use the same calculation steps. You'll notice overlays and RA don't invert.

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.

The only different between my monitor and your monitor is the X/Y offsets are different so the frame is displayed centered at the native resolution. If you add the offsets to the game resolution you get the native resolution of each monitor. But our game rendered frames are the same size.

I think you asked a great question. I don't know but maybe the final frame is "padded" to the native resolution but I don't think it's rendered at that resolution as it would be a resource nightmare. I think it renders the game frame and uses the offsets to display it on a specific x/y coord on the screen. Could you imagine rendering natively at 4k!

Also another reason I would be curious I do actually use a lot of custom portals. I wonder if the game frame is rendered at that portal resolution or another resolution and then upscaled/downscaled to the portal size.

I don't think you can leave the monitor to do scaling as it would look rough. I think it needs to use some technique like nearest neighbor or other scaling techniques to look half way decent.

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