Backdrop artwork low resolution

[UDb23]

Just recreated Skydiver backdrop artwork in 1080p, artwork resolution set to 2 thru RGUI and still graphics look very pixelated. Note: game area width is 1152 pixels wide and the "skydiver" text bitmap (png file) now has the exact same size; still looks blurry. Working on Pi3 B+, no overclock, no shaders. There are other backdrops I could recreate in high res but it makes no sense if in the end the displayed res is low. What can be done to fix this ?

[Wilstorm]

Actually no, not all points are covered. If you would read the OP and a few down where he posts screenshots it would help.

I have no idea why you keep posting GPU enabled screenshots. If they look different from the actual game screen you view and play on they are pointless. Especially since the resolution of those screenshots are 512x448 and not 1440x1080 as they should be for testing.

To the point your snaps are 512x448 or 1024x768. The further the image is from the original resolution the more prominent and pronounced the distortion and "jaggedness". You need to bring them up to 1440x1080 for HD which will further distort the image then it will be an apples to apples comparison. It looks terrible on an HD TV and even worse at 1600x1200.

If you would test with RetroPie you would see that "GPU enabled screenshot" doesn't exist under Settings -> Video. Any chance you could post screenshots using RetroPie 4.4.4 on a Pi 3 hooked to a TV? Then we would all be on the same page.

All @UDb23's overlays and backdrops are created with HD in mind. Again I'll let him decide if it's satisfactory in HD to continue his work.

Fact checking! =/ The post starts with "my screenshot from ra. Can you check our aspect ratio settings" (original backdrop posted).

Then below that you post another stating "and another with gpu screenshot enable off the way i always use it."

I did make the assumption the first one was with it "on" since the one below it you state it's "off". Either way it's the original zip backdrop.

Your "my screenshot from ra. Can you check our aspect ratio settings" screenshot:

File: 51875044-42218580-235b-11e9-8a21-f8f1ef1495a2.png
CRC-32: e1170b8c
   MD4: 6b7f83d22cf981d2f63214e087744b90
   MD5: 5c0caf7ea2806628ad7eb91f0d886746
 SHA-1: f27b66ad58e1e023e77986e78256d39871789910

Original boottest.png:

File: boottest.png
CRC-32: e1170b8c
   MD4: 6b7f83d22cf981d2f63214e087744b90
   MD5: 5c0caf7ea2806628ad7eb91f0d886746
 SHA-1: f27b66ad58e1e023e77986e78256d39871789910

Anyway I'll be done posting now on this issue because I can't get you to match @UDb23's setup to get on the same page. Shoot I can't even get you to post an actual HD (1440x1080) screenshot vs posting the original backdrop or a low res 1024x768 one.

I wasn't expecting us to be gregarious but at least amicable on core issues but I just don't see it. Anyway I'll keep out of this issue and hopefully @UDb23 will review the snaps. Relax. Give him some time as he travels for work and will post when he has time I am sure. I can't answer your questions. I closed the other issue relating to overwriting backdrops.

It's your core. You can leave whatever you want "broken". We can only bring the issues to you and what you decide to fix is solely up to your discretion as you have complete autonomy on the project.

[Wilstorm]

Just to review this is actual backdrop next to in-game screenshot using @UDb23's test backdrop he created. Both are at 100% with no modifications. You can't see the difference here?

[ghost]

I guess im missing something here the artwork is not 1080p you display any game at 1080p with no sharders or filtering its going to look like shit.

the disable gpu screenshot is what mame is outputting without any scaling applied mame will need to output 1080 for what you want to do. So can you explain how you plan to make mame output 1080p in detail?

Space invaders works fine on 720p as well why are you trying to lock everything down to 1080p

I can post screenshots in 1080p if you like it doesnt matter of you are on a pi or windows it down to adding shaders ect.

[ghost]

ok taken on a pi like your example shaders off and both 100% one is gpu enable off and the other is gpu enable on.

[ghost]

the pi screenshots one with biliniear filters the other not . dunno what you obsession is with using the pi :) 1080p as well

[ghost]

the two above and the original 100% from the pi at 1080p

[ghost]

no sure if the one above i right i downloaded from the pi and re did it.

[ghost]

i can post my retropie configs if you want them just let me know what ones you want. Im not sure what res was posted the 100% earlier it certainly looks scaled very different to mine at 1080p

[ghost]

At a guess i would say you guys are setting custom configs on the pi for the res

tvservice -s state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive

tvservice -m CEA Group CEA has 13 modes: mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive

tvservice -m DMT Group DMT has 10 modes: mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive mode 6: 640x480 @ 75Hz 4:3, clock:31MHz progressive mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive mode 11: 800x600 @ 75Hz 4:3, clock:49MHz progressive mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive mode 18: 1024x768 @ 75Hz 4:3, clock:78MHz progressive mode 21: 1152x864 @ 75Hz 4:3, clock:108MHz progressive mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive mode 36: 1280x1024 @ 75Hz 5:4, clock:135MHz progressive mode 82: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive

i stick to prefered

(1600 x 1200): is beyond 1080p ask on the retropie forums for video timing info and if it possible

[ghost]

@Wilstorm the core does not copy the artwork i explained this to you on that issue page retropie setup script does it.

I told you to post on there github page or the forums. We have been round this before i only contribute here in no an admin i gave that up. Ask mark to ask them if you dont want to ask them yourself. I gave you the info to where the script does the copying but im sure mark will ask for you if you dont want to do it yourself

[UDb23]

@Wilstorm @grant2258 I finally was able to read all your posts from the last days. As @Wilstorm correctly guessed, work kept me away. Let's try to break down the problem into specific topics that need to be fixed. First I'd suggest we find common ground to start from and get rid of any misunderstanding.

1. HD RA overlays applied on top of mame backdrops are displayed perfectly in HD (while the backdrop, whatever resolutions the BD image is, looks blurred). Therefore issue is NOT related to screen resolution settings of the Pi but depends solely on mame backdrop rendering code. Note: I do not use any shader; just plain 1080p resolution.

2. As I create HD mame backdrops for 1080p screens, they MUST look perfect on 1080p screens (or higher) without any smoothing/bilinear filtering.

3. Screenshots and how to make'em. Let's just take pictures (e.g. with your smartphone) of the screen (sure jpg will apply some compression but if we keep the shot at original resolution and maximum quality it is enough to check if the screen output of the BD is HD or not).

4. If you have a monitor ( or TV) at 1080p and your Pi outputs 1080p mame2003plus will generate (upscale) the game graphics using, per ROM, "core provided" aspect ratio. This means, as @Wilstorm mentioned, for example that (without any BD or RA Overlay) game will be rendered (upscaled from original arcade res) at 1440x1080. So if I create a 1440x1080 BD it must be displayed perfectly at that res (it exactly matches game res) and without needing any smoothing/bilinear filtering.

BD that extend outside the game area may behave differently depending on the "size" coordinates settings in the .ART file. For that reason lets stick just to game area only BDs for the moment.

5. I created the boothil test BD at the resolution you requested (I image you wanted to match with 2x game res / 2x artwork setting). Again that BD will never look good on at 1080p. In the end the code at some point will upscales game graphics (and BD I fear) to 1440x1080p as said in 4.

Do we all agree on these points ?

[UDb23]

@Wilstorm BD overwrite issue. I think this can easily managed by adding BD functionality to current @meleu's script that installs the overlays. In that way user can select what BD he wants to install. It could also be able to "backup & restore" BDs eventually overwritten by mame2003plus updates. It's my fault I couldn't find the time yet to describe the requirements to @meleu (he already kindly said he will look into this as soon as I provide necessary info/steps).

[ghost]

I want to explain to you why im using gpu enable off. We need to see what mame is spitting out (resolution wise) and invaders by example.

If you want your artwork to be 1080p well mame needs to output 1080p else your going to need filters when using the artwork.

now if you run this in 1080 and 720 the mame resolution remains the same mame is spitting out 540x1195.

So whatever you done to get outside of the internal resolution on invader your going to have to do the same on boothill.

1080p and 720p gpu screenshots enabled off.

(1080)

(720)

[ghost]

sorry i the artwork scaling on x2 on my windows machine ill check both again

edit and the pi lol

[ghost]

the artwork isint working in hd currently artwork x1 is showing as 270 x 597.

pi 1080p

windows 720p

[Wilstorm]

It could also be able to "backup & restore" BDs eventually overwritten by mame2003plus updates.

That would be a great feature! :) Yeah I agree with all your points listed above.

@grant2258 - If you were able to extract what you needed from GPU enabled off. I imagine the original frame resolution is very helpful when looking at code and troubleshooting.

If you turn it on it should look correct if you're running RetroPie 4.4.4 with 'auto detect' on an HD monitor or TV. I get the same results as you shown below.

The first one is 'off' and the 2nd is 'on'. If I bump the multiplier to 2x it's the same as yours also. If I was going to take a guest I would say GPU Screenshot Enable OFF is just showing you the frame in a state of pre-processing basically before it's rotated, upscaled, shaders, filters, etc. and with it 'ON' it's post processing.

Of course 720 and 1080 will give you the same resolution with it 'off' because it hasn't been processed for the target display yet which would be 1080 shown below with it 'on'.

GPU Screenshot Enable OFF (270x597):

GPU Screenshot Enable ON (1918x1080):

[ghost]

@Wilstorm gpu enable off its what mame is spitting out before pre processing that why ive been posting the screenshots. If you want 1080p backdrops mame needs to spit out 1080p resolutions.

[ghost]

do either of you have a boothill artwork file at 1080p 4:3 1440(width) x 1080(height)

the game resolution itself is a 8:7 aspect ratio that would be a 1080 x 945

im assuming you guys have tested the 4:3 already if you could provide the artwork files for both it would be appreciated for testing some stuff

[Wilstorm]

If you want 1080p backdrops mame needs to spit out 1080p resolutions.

I disagree with the statement above. Do you have any examples that render at true HD resolutions with GPU Screenshot Enable OFF?

@UDb23 has created 3 BD's up to today. The first two render at a lower resolution (SI is 2x) and then are upscaled to HD and look perfect. Those two games are Omega Race and Space Invaders. Both have submitted PRs and are available for testing in the core.

Sky Diver on the other hand also renders at a low resolution but when upscaled looks jagged as shown in the OP.

Boot Hill's game aspect ration may be 8:7 and has a resolution of 1080x945 at 4x integer scale but if you use that resolution you're going to have a fatter cowboy. Remember modern displays use square pixels so the display aspect ratio will be incorrect. Regardless using Core Provided wouldn't calculate that resolution and also isn't the target.

We should stick with using Core Provided resolutions as they will produce proper HD resolutions and integer scaled resolutions will not.

I don't believe there's a HD Boot Hill backdrop to test with right now. Would it be possible to use the OP example and use Sky Diver for testing since it does have a BD that we all have access to as I believe @UDb23 submitted a PR for it.

Also would it be beneficial to look at the code for the two games that do work properly with HD BD's those being Omega Race and Space Invaders.

If it helps BD's are positioned relative to the game play area size so they may scale and aren't an absolute value.

I think BD's are fairly important to having a complete game play experience. Without a backdrop in Boot Hill it would be two token white guys on a black screen. Another game that is almost backdrop mandatory is Armor Attack. It has "buildings" that you need to drive around or they would be "invisible" without the backdrop. Another is Demon with it's "space rocks". There's a handful of games that really benefit from BD's to make the games complete.

[ghost]

@Wilstorm I asked for two artwork filesfor testing what exactly are you disagreeing with?

[Wilstorm]

@grant2258 - I just told you it wasn't available and to use Sky Diver, it's available to all of us in the metadata folder. What exactly are you asking?

[ghost]

i need a png them dimensions

[Wilstorm]

I have no idea what you're talking about. The correct artwork file with the correct dimensions is available in your metadata folder for Sky Diver, it's named skydiver.zip. The OP lists Sky Diver as the game with an issue. I think it's best to use that game for testing.

[ghost]

@UDb23 can you give me the boothill artwork(png) for boothill and them dimensions that above.

@Wilstorm if i wanted to use skydiver i would have asked for sky driver can you please stop being argumentative for no good reason

[ghost]

clearly form you pic of space invaders it isnt scaling properly either look at the shape of the planet.

your gpu enable off roated

your normal screenshot

[UDb23]

@UDb23 can you give me the boothill artwork(png) for boothill and them dimensions that above.

Sure I can. I can do even better: create a test picture like the ones used for camera tests. At "core provided" aspect ratio horizontal games have 1440x1080 game area and vertical ones 810x1080. Therefore with test images for these two res we can check all games. Will let you know asap.

[Wilstorm]

The original post is an issue with Sky Diver. It is available right now, has the correct dimensions and is also in the correct format. Why would you not use what is available and also pertains to the exact issue? It's the logical choice.

Boot Hill on the other hand will need to be created, which may some take hours. It's a complex backdrop that will need a lot of work, plus it will need exact positioning of the BD text and a zip archive created. It doesn't make sense.

You've posted BD's from Boot Hill, Space Invaders, Robocop but you refuse to use the BD that is listed in the issue. Why?

lol...again...that is a pre-processing pic that is using 2x integer scaling, of course it's going to be off. SI displays perfectly in game with maybe a 2 pixel squish on y axis in game that you can't notice visibly. There's no reason to pick at SI as it displays perfectly to the original BD @UDb23 created. Who's being argumentative for no good reason? You can't have your way so now you're going to pick apart Space Invaders? Give me Boot Hill or I am taking my ball and going home? I don't get any of this from you. It's like a teenage argument with you on everything.

Probably more true you truly don't understand how the .art works or art positioning. Do you not understand that pic will be scaled to a proper display aspect ratio with a Core Provided resolution, before it's sent to the screen, that has absolutely nothing to do with the integer scaling? There's a huge difference here that you're not understanding or playing coy. I don't know.

You really just need to stop posting pics that you clearly don't understand what's happening. It's about the equivalent to pulling a car in the middle of production and saying "See I told you it doesn't roll and the air conditioning is broke." That pre-pic has absolutely nothing to do with what's displayed on the screen while actually playing the game but you're already aware of all this.

Ok, since you're being silly I do hope you have yourself a good day. I don't want to waste anymore time today. I try and give you just a little time each day in one or two posts in hopes you might want to actual fix the issue but clearly I see you don't. Good day sir.

[ghost]

boothill was the issue issue we are talking about with the test circle can you clarify?

I dont get you at all there even a circle picture with a test clearly that is an issue talked about. Maybe skykid is your own person issue. Im getting tired of trying to help here honest you just so argumentative.

Let me tell you something about understanding you want to use 1080p artwork thats pumped out at normal game res to upscale properly to 1080p from a lower res and wonder why there is issues. You clearly have no idea how this is all working

[UDb23]

I still think the issue is related to the sequence & way the game graphics are applied to the BD. Unfortunately I don't know c and mame enough to be able to analize the code.

As already said, correct processing sequence of BD should be: -upscale the game graphics (according to 'core provided') to actual screen resolution (e.g. 1440x1080) -scale the BD image to fit actual screen game area resolution (same as previous:1440x1080 in case of 0,0,1,1 coordinates in the .ART file). If BD png image already 1440x1080 no scaling of BD should happen/be needed)

• "blend" game graphics with BD.
• output to screen

@grant2258 can you check if this is how mame2003plus behaves?

[ghost]

@UDb23 the artwork runs withing mame core iit isint pumping out 1440x1080

a more accurate disciption of whats going on is

"blend" game graphics with BD.
output to screen

(gpu enable off output)

ra then scales this all up to 1080p

[ghost]

I think we need to take the pixel aspect ratio as well as the the aspect ratio into account when doing this its why i requested them pngs for testing

[UDb23]

ra then scales this all up to 1080p

that would explain why RA 1080p overlays are perfect; probably placed on top AFTER scaling game and BD to 1080p.

working on the test images

[ghost]

you can get a clearer picture of whats going on if you make some art file with triangles circles and squares (filled with a color) and put a detailed picture in it.

[Wilstorm]

@UDb23 - Yes that sounds correct to me. I would clip the BD so you can keep the positioning simple at 0,0,1,1 and definitely it shouldn't need filters or shaders since it is already hi-res. If you need anything just let me know. I apologize for the long drawn out posts as Grant and I have never gotten along since day 1 when he was learning how to use DATs and I tried to help him, clearly it was new for him and he took offense.

@grant2258 - Please do share your vast and encompassing knowledge that is all inclusive on this issue. I would assume there would have been no need for this long drawn out conversation. That you would you have fixed the issue by now.

Scratch that, I prefer you not explain the issue. I am sure I'll get along just fine with out and remove myself. I've watched you "alligator roll" to many times on issues and twist up the points so nothing really makes sense, even with the RA devs on the input system, they were correct.

I know you know better and are quite intelligent but all I see is bunch of anger and rebellion from you. I revere the overlays and BD's @UDb23 creates and wanted nothing more than to participate and see this Issue succeed but you truly just like arguing with people.

To be honest this just isn't an issue at all for me Grant. You've done me a favor actually. I promise not to ask for your help on any Plus related issue here. In fact it should make my life less complicated. Heading out for lunch and have yourself a good day.

[ghost]

@Wilstorm all you do is look for argument dont you :) I pointed out many times on this thread that mame doesnt output 1080p it not my fault you cant work it out.

[UDb23]

Test image created @ 1440x1080. Multiple patterns and shapes included.

@grant2258 @Wilstorm We're all doing this in our free time and I'm pretty sure we all have little free time anyway.... we shouldn't waste it.... don't think any of us is looking for/to argument.

[UDb23]

BD test image has thin 1px red border box with another green 1px box inside: to verify if image is cropped.

[UDb23]

@Wilstorm -45C temperature !! Your weather is in the news this evening in Italy. That's crazy. No way to get outside I imagine !?

[ghost]

@UDb23 as ive mentioned above maybe add a 3x scale option so things scale up nicer you can see the effect the scaling has. Its not perfect but should make the backdrops look a lot better when they are in hd

[ghost]

ok ibe looked into space invaders and it looks like it works properly with the artwork set to 4:3 (i just rotated the image) It looks like mame reports a 4:3 to retroarch and the artwork changes the aspect ratio and thats why RA is squashing it up.

gpu disabled

gpudisable rotated

gpu enabled

[ghost]

you can clamp the invaders artwork yourself change the resolution to 4:3 ie resize it to 1080 x 1440 and thats what it looks like when ra renders it as 4:3.

You guys wanted the aspect ratio fixed to crt monitor for bezels . The only thing is a crt monitor doesnt have an aspect ratio. I didnt want this change in particular and space invaders did work properly before you requested this change. I dont feel too strongly about this subject though

here is the screenshots gpu enabled for space invaders before and after you guys requested a aspect ratio clamp. https://github.com/libretro/mame2003-libretro/issues/394

this change is directly on account of you guys forcing the aspect ratio rather than what mame was outputting its what you wanted for bezzles to work.

before aspect ratio change.

after the aspect ratio change

since your clamping the aspect ratio you need to clamp your artwork as well its something to keep in mind

[UDb23]

@grant2258 thanks for all this testing. I understand the 4:3 ratio is applied (forced) also to BD. No issue considering this when I create BDs. Actual size on screen of BD is managed by .ART config file settings thru its coordinate system; SI is a special case where the BD extends outside the game area. The BD png image in fact is much wider than 810x1080 (game area).I can tweak the coordinates to get the right aspect proportions. I think we should test BDs that cover the ROM's game area only, so output is not influenced by .ART coordinate stretching the BD image. To actually verify SI's BD resolution output an 810x1080 game area only, a test image with that res is needed + specific test image. Will do that this evening.

Still it is unclear to me why a artwork multiplier setting is needed to render better BD. Game graphics are upscaled (mame+RA) anyway up to 810x1080 (or 1440x1080) anyway when there's no BD image active, and AFTER that those graphics are then blended with BD that's already at that res; what needs to be upscaled/multiplied?

[ghost]

It works like this if you have an image of 200 x 400 and upscale it to 1080p it looks crap. If you have a image of 400 x 800 is still not perfect bit like with game a shader or bi linear filtering will fix it up.

The confusion is coming from you thinking the bd is processed at high resolutions it processed at mames resolution then its all upscaled together.

because your outside the game area in space invaders you increasing the resolution so it scales with better detail.

space invader original resolution is 240 x 224 the artwork changes that too 270 x 597 x1 artwork scaling and 540x1195 x2 it also changes the aspect ratio. it should be clear 540x1195 scales a lot nicer than 240x224

now to add to the confusion since we clamp the mame to a forced aspect ratio now you need to match the artwork as well so it all stretches properly when you go outside the game area.

[ghost]

you can see it scaling to mames resoultion. test x1 an x2 with the test gfx no need for any tweaking just make the invaders bd like you did with the test gfx then rotate and save your done.

invaders.zip

[UDb23]

The confusion is coming from you thinking the bd is processed at high resolutions it processed at mames resolution then its all upscaled together.

Understood. Any chance then to change mame artwork rendering sequence? I mean, with no BD, mame + RA upscale the game graphics to "1080p best fit" according to "core provided" (or any CFG set aspect ratio). No way to change the code to BLEND the game graphics on top of HD BD AFTER game graphics have been upscaled ?

[UDb23]

vertical game area testing BD image here (810x1080).

Space Invaders BD art with rotated test image here.

[ghost]

Well that is going to look worse you put the game back to it normal resolution 240x224 the other artwork increased the mame resolution which is what you want to do for better scaling. If you make artwork 1080 x 1440 like the test imahe and rotate it with the old artwork it will work fine and look nice.

The only real viable option for what you want to do is for ra to do backdrop artwork like it does overlay which it doesnt support at the moment else the core would need to run at 1080p and that would not fair well on a pi

[UDb23]

The only real viable option for what you want to do is for ra to do backdrop artwork like it does overlay which it doesnt support at the moment else the core would need to run at 1080p and that would not fair well on a pi.

Basically, if I understand correctly, to get best results we should set 2x artwork multiplier and make a "bigger than game area" BD PNG image to "force" better res for the BD ? Also this means we'll never get full BD res with current .ART on the Pi, correct?

Then I think I'll keep making high res Overlays and not invest any more time in creating high res BDs (sorry @markwkidd) until someone will implement RA BDs.

[ghost]

Yes that is correct and will be true for all cores unless they run hd res. Mr do has some old artwork anyone can use its not all bad news I do understand you not wanting to make low res artwork but it what your working with atm

[markwkidd]

I think this discussion is definitely looping back around to the question of artwork performance, which limits AdvanceMAME too AFAIK. It's one of the cardinal reasons for wanting artwork support in the frontend.

Does anyone know if AdvanceMAME is able to squeeze out HD display performance (incl. backdrops) on a Pi with these same titles?