Backdrops in mame2003-plus

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.

Clyde

@quicksilver Thanks, I just wanted to pave the way for @UDb23 a little bit with my request. 😌