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 ?

[ghost]

Where is the overlay ill take a look tonight and see how its looking for me.

[ghost]

speaking of skydiver i dont an update the sounds better for me on windows anyway.

https://github.com/libretro/mame2003-plus-libretro/pull/597

it was a pretty big update had to update a few drivers for the sound core update

[UDb23]

My pull request for the high res backdrop was accepted so it's now part of mame2003plus. Link here.

You did a fantastic work with Skydiver sound. Makes playing it totally different, thanks!

[ghost]

here is a screen shot taken from windows on my laptop what the issue with it?

[UDb23]

Your image looks ok and smooth. This is how it looks on the Pi: note the pixelated border of the letters (and how sharp the image on the left is, part of the RA overlay so not generated by .art mame artwork system)

[Wilstorm]

Here's another example. It's Boot Hill the backdrop is exactly the size of the monitor and positioned correctly. In the zip it's readable but in-game it's very distorted and unreadable. Here's a pic to show the difference. I've seen this in more than one game.

[markwkidd]

@UDb23 there is definitely value in creating hi resolution artwork. @Wilstorm I know it's not a good thing to hear that this has to be an issue with your setup on another issue but that seems to be the case.

I just took this screenshot with an unmodified boothill artwork pack from Mr. Do's. With my artwork resolution multiplier set to 2x in Windows I get results much closer to your "Original" screenshot:

[markwkidd]

I zoomed mine 2x to be closer to matching your comparison

[markwkidd]

And finally, here is the full screenshot

[Wilstorm]

It's not my setup. I wasn't using Mr. Do's artwork it was a much higher res backdrop that's why mine is much clearer than what you just snapped but thanks.

[markwkidd]

Ah I didn't see where you posted that. In order to troubleshoot we all need to be using the same file. You might post yours. In that way, it kind of is your setup because you are the only one running the core that way with that artwork :)

I don't think that Mr. Do's artwork is very high resolution.. 912 x 677. That being said I do think that resolution could account for your issues.

I seriously defer to other expertise in this discussion because I haven't been looking at the artwork closely but that being said, shouldn't backdrop artwork be scaled to the game being emulated rather than the monitor?

I think if you have backdrop art scaled to your final display size, it may end up getting rescaled two or three times depending on how retroarch is set up by the time it appears on your screen, which would account for that kind of quality loss.

edit: I have honestly not traced the scaling logic through all of these layers so I'm hoping that grant or someone else will say if I'm wildly off base here. I do think that there resolution of your backdrop file is involved.

[ghost]

what I can tell you is we so the vector resolution differently than mame078

mame078 does this if (options.vector_width == 0) options.vector_width = 640; if (options.vector_height == 0) options.vector_height = 480;

we do this if (options.vector_width == 0) options.vector_width = Machine->drv->screen_width; if (options.vector_height == 0) options.vector_height = Machine->drv->screen_height;

then the multiplier is added (both) / apply the vector resolution multiplier / options.vector_width = options.vector_resolution_multiplier; options.vector_height = options.vector_resolution_multiplier;

The artwork scale setting does not apply to vector games it always set to 1x scale. So to make your artwork the original game resolution

[markwkidd]

Yes that's what I mean when I say it seems to make the most sense to scale backdrop art by the size of the emulated game because that's how it gets handled internally

Again, bezel should in my mind scale to the display being used. Backdrop is tied to the emulated video so it should probably be at a multiple of that. Right?

On Tue, Jan 22, 2019, 8:24 PM grant2258 <notifications@github.com wrote:

what I can tell you is we so the vector resolution differently than mame078

mame078 does this if (options.vector_width == 0) options.vector_width = 640; if (options.vector_height == 0) options.vector_height = 480;

we do this if (options.vector_width == 0) options.vector_width = Machine->drv->screen_width; if (options.vector_height == 0) options.vector_height = Machine->drv->screen_height;

then the multiplier is added (both) / apply the vector resolution multiplier / options.vector_width = options.vector_resolution_multiplier; options.vector_height = options.vector_resolution_multiplier;

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/libretro/mame2003-plus-libretro/issues/607#issuecomment-456630082, or mute the thread https://github.com/notifications/unsubscribe-auth/ASphdlenmv0Tg56AOhGtq4J5voKGHLTfks5vF7m0gaJpZM4aJkUC .

[ghost]

Well in all honesty I havent looked into the code much aside from changing the the default scaling to 2x or 3x for vector games for the reasons above.

fyi: boothill game resolution is 256 x 224 you can change your artwork res on teh multiplier you using i would imagine.

like x2 would be 512 x 448

[ghost]

@markwkidd change this here

https://github.com/libretro/mame2003-libretro/blob/bb098b6d773c81a7d66bd9a26f8f835bfcacd781/src/mame.c#L825-L826

to original mame setting then set your vector res to x1 an retry the artwork is should fix old mame artwork up.

nm i downoaded the artwork from mrdo its smudged anyway

[2xtime]

On top of this, some people are also adding an overlay at 1080p. So they have the backdrop art at the game resolution and then a 1080p overlay on top.

[Wilstorm]

I was collaborating @UDb23's findings on distortion in HD backdrops using a HD backdrop to help facilitate the issue.

Does vector games handle it differently as Omega Race looks correct in HD but then again so does the Space Invaders and it's a non-vector game.

Boot Hill might be an exception. I setup that first spreadsheet that does calculations and if you notice the positioning -0.26250,-0.24375,1.26250,1.16670 it's actually scaling up. It needs to be larger than the game area to align the score, time and shots of the backdrop. Since the game has a black/blank background it might still be game area though.

@2xtime - So they have the backdrop art at the game resolution...

Do you mean at the display resolution? If it was at the game resolution it wouldn't be an issue.

UDb23 is aware it's 1080p and it does take a performance hit. I think one of his goals was to fill in "black" areas on 1080p TVs. Which this does achieve that goal, especially when not using an overlay.

When using an overlay you need to set the opacity to 100% to avoid bleed-through of the backdrop.

Though I wouldn't mind seeing the backdrop match the game area size as I never set my opacity to 100%.

[UDb23]

From testing so far it seems code manages BD artwork res differently in vector games vs raster games. Still I need more testing to confirm this. Just to clarify I'm talking of mame2003plus running on Pi (not windows). Concerning raster games what I would suppose the code to do for BD is that BD is rendered at actual screen resolution and the game graphics are placed on top. Game resolution of course follows mame/RA game resolution settings (e.g integer scale, 2x, 3x, custom etc.). In any case before displaying on screen the game graphics are in the end "upscaled" to fit the monitor/screen resolution. This is the way RA overlays work and, in fact, RA overlays are working in full resolution regardless of BD enabled or not (just try skydiver with BD and RA overlay on top).

What apparently actually happens with BD is that BD is "downscaled/resamples" to the set game resolution (e.g. 2x or 3x); game and BD are then "upscaled" to fit real screen resolution. That would explain the smudged/blurry BD final result.

Any thoughts on this ?

Will update a test BD I specifically made just for screen res testing; I would suggest we then select a specific raster game and try to find why and how to fix this res issue.

[UDb23]

Performance and "bleeding" of BD when using RA overlays are different issues and can be managed separately once we fix the BD res issue. I'd suggest to keep these separate for now.

[UDb23]

Battlezone (vector) arcade cabinets used cardboard backdrop; it is available as .art BD at medium res at MrDo's discontinued art web page. Actually it's a bezel that goes on top (not below) of two (red and green) gels that simulate color. All these are on top of the actual game emulation graphics. Therefore it can be recreated also as RA overlay. Going to recreate this in vectors so we get a high res version and then create both the RA ovl and the .ART BD (identical images) This way we can see the differences in terms of quality and res between the two different implementations of the same artwork image.

[Wilstorm]

I agree vector games are doing things differently as Omega Race BD displays perfectly.

But on the other hand the Space Invaders backdrop you created, being a raster game, works perfectly also. Would maybe looking into how vector and specifically Space Invaders do it shed some light?

Maybe 3:4 games like Space Invaders are fine but 4:3 games like Boot Hill are incorrect. Just trying to find the pattern.

I have that code Grant pointed out stuck in my head to something like 640 x 480 x display multiplier.

I look forward to seeing the difference in Battlezone but that's a vector game too. Would it be worth it to also do a raster game, one of each?

I agree bleeding is a different issue and easy to solve. I cropped my Space Invaders BD to the game area resolution, updated the .art file positioning and it solved that issue. :)

[Wilstorm]

Just a thought though is I almost prefer the BD to match the game area only though. I find myself looking all over the screen when it's filled with a BD and there's no defined boundary. It makes the game look small but with overlays it feels more focused to just the game area and really works for me.

[UDb23]

Agreed, we need a raster game for res testing reference too. Was thinking of Space Invaders part II as I found high res artwork.

[Wilstorm]

That sounds good. Also slightly off-topic is I did go through the Plus DAT and added all the clones to the Artwork spreadsheet. I figured it's a good reference for all games that have Artwork in Plus. I was going to shade rows with the parent one color and rows with the clones another color but I didn't want to make a bunch of changes to your spreadsheet without you reviewing where things are at first.

[ghost]

try making your artwork 512 x 448 for boothill

[UDb23]

@Wilstorm thanks for adding to the artwork sheet. If you wanna also edit anything you think is relevant with colors etc., more than welcome. @grant2258 yes I can do for testing, but for sure will not look good at that res. It is still useful to see how it gets scaled together with game emulated graphics.

[UDb23]

try making your artwork 512 x 448 for boothill

Here's the test backdrop for Boothill. It's a crop to the game area only, so test results are not affected by any "wider than game area "rescaling. Res is 512x448 as requested. As the BD is good res but the original image is blurry, I added test text, circle and line.

[Wilstorm]

@UDb23 - That's an interesting test. The text, line and circle really help. It's quite blurry in game vs. your original BD.

Also you need to add backdrop: to the .art file or it won't load. It took me a bit to figure out what was happening. I resized the image, recalculated positioning and finally start creating a new .art file before I found the error.

[ghost]

yea i noticed it wasnt loading for me either will look into this in a bit just wanted to get the input updated.

[UDb23]

Sorry guys, I apparently deleted the required line without noticing. Zip file should now be ok.

Finalizing vector backdrop for Battle Zone; noticed that red and green color "film" are already generated by the driver in lr-mame2003plus (std lr-mame2003 is white only). Also default button settings for gamepad already map the 2 analogs to drive the tank like the 2 original joysticks: nice !!

[Wilstorm]

Here's a comparison snap between the original backdrop and in-game with the test text, line and circle @UDb23 added. They are both at 100% with no modifications. My artwork multiplier is set to 1.

The display I used is native 1920 x 1200. The game scales to 1600 x 1200.

[ghost]

is it just that one spot bluring or is it the whole image?

[Wilstorm]

@UDb23 - I'm not sure but I think when @nayslayer was doing updates he fixed a whole bunch of things. I suppose that's why he said he almost raged quit. One thing lead to another to another to another and he fixed a lot of things.

@grant2258 - Yeah the whole image is that way except the actual game is sharp. I was just trying to show a sample but here's the whole images for you to view.

Original (512 x 448):

In-game (1600 x 1200):

[ghost]

please try setting your artwork scalex2 since its double the res

[Wilstorm]

Here's a screenshot at 2x artwork multiplier.

[ghost]

original just for reference

[ghost]

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

[Wilstorm]

Yeah, it's 1600 x 1200 "Core Provided" on a monitor that is 1920 x 1200 that's 3:4 ratio maximized on my screen.

If you're getting that on a Pi 3 that would be interesting to know the settings? Even a 1:1 on a Pi 3 is squeezed on the y axis.

[ghost]

ill leave mame compiling im just about to catch some zzs. I havent had a good day my cv boot clip ripped off my car and destroyed the control arm boot. Ive ordered a new control arm ill fit it tomorrow weather permitting. I really hate working on the car in the winter.

do you want the screenshot for ra or raspi2png

[Wilstorm]

Why would I want you to use raspi2png? I use RA as the screenshots seems to match the screen exactly. Is that how you got the 512 x 448 screenshot?

Your screenshot posted is a 512 X 448 which is a 1:1 PAR x 2 so an 8:7 DAR. I have no idea how to recreate that without using a custom viewport of those exact dimensions (which I did) and even then it's still not the same as you can see from my screenshot below. I would guess the processing steps before displaying the backdrop are deteriorating it from the original but it still needs to be upscaled for HD.

So how exactly did you create that screenshot as yours matches the original exactly? Using Windows gives you a pixel perfect screenshot? I tried everything I could think of and that's just not possible at the defaults it seems and even using a custom viewport and a bunch of tweaking it's still has jagged edges.

In fact the screenshot you posted and the one in the artwork zip file @UDb23 created have the same exact same CRC hash e1170b8c.

I haven't been under a car working in the winter for a while now, hopefully all goes well. We are going to get brutalized tomorrow night into Wednesay. -20F/-29C with wind chills in the -50F/-45 or so. We always get this for a week or two in January of freezer box cold but the good is once it hits 30F/-1C it actually feels pretty decent outside and a light coat works because it's a 50F/75C degree warmer difference.

[ghost]

ill post both again dont know if i posted the wrong one just took a screenshot in ra ill let the game start and take a zap. Im pretty .sure i posted the right one. i just pressed f8 in retroarch n windows.

[ghost]

and another with gpu screenshot enable off the way i always use it.

[Wilstorm]

Ok well, I digress, maybe someone else may test it on the Pi and have better luck. Everything I tried looks low res and jagged edges except Omega Race and Space Invaders.

[Wilstorm]

@UDb23 - I know you opened this issue so if there's anything I can do to help you troubleshoot or test please just let me know.

Grant posted your actual backdrop image as a screenshot or he somehow unzipped the backdrop and accidentally got it mixed in with his screenshots that have very different, long names and posted it.

Either way it doesn't matter as all his test screenshots are on Windows or they are at the native 512 x 448 resolution which doesn't help at all because the goal is to create HD backdrops for 1440x1080 or 810x1080 with RetroPie on a Pi.

I did get an image created and pishrunk this weekend it before all the analog, legacy remapping, dual config challenges went into the current build. I am set and don't plan to upgrade anytime soon or will spin up a new image for any testing as I don't use SNES controllers or anything similar that doesn't have analog. I don't think backdrops will get fixed until Grant feels like helping at some point I guess.

Anyway just let me know if you need any help testing here or in the RP backdrop forum thread.

[ghost]

@Wilstorm let me clear something up. RA can take screenshots two ways in ra one form the gpu or from the image rendered itself settings->video gpu screenshot enable on off.

I did not post the original image you assumed i did i still dont think i did . The last two images are one with gpu screenshot enable on and the other is with gpu screenshot enable off. The ones that have game gfx in them, Im not sure what else you want a screenshot form the pi ?

[ghost]

it working fine for me on retropie well after a bit of manual editing the game options dont seem to be applying properly for me well the overrides.

do this

cd /opt/retropie/configs/all/retroarch/config/MAME 2003-Plus delete any over rides or move them somewhere safe

edit /opt/retropie/configs/all/retroarch-core-options.cfg set mame2003-plus_art_resolution = "2"

start the game and it will look like the screenshots i posted above

[Wilstorm]

You make me laugh some days and not in the good way. In all honesty you've become predictably obtuse now when it comes to asking for help. It becomes something of a renaissance for you it seems.

Thanks for the clarification but no one asked for two ways to take screenshots. The 3:4 (1024x768) looks like some type of "blurring" or "smoothing" or some filter effect has been applied or maybe Windows Libretro or RA has it on by default.

Also it's not HD as it must be an older desktop or laptop to only be 1024x768. If you do any work in Photoshop that pic posted above is screaming it's been smoothed. Just look at the text edges in the GPU enabled one, see that blur, that's been upscaled (to 1024x768) and smoothed or it would just have jagged edges.

That's the funny thing about SHA-1 or MD5 hash they are fairly precise. I just don't believe that you can capture a screenshot that has the exact same hash as the original contained in the artwork zip. That would be a neat trick in the nano or microseconds before a sprite is drawn. One pixel deviance of any game sprites on top will change the hash, so yeah I think you did it just to be precarious. Does GPU screenshot enable on/off change the actual game play screen or the just the screenshot? Are you just showing us different screenshots or is the actual play area change with that option? Geez.

If you re-read the OP he clearly states he's using the Pi 3 B+ and not Windows but you managed to post 4 Windows images and 0 Pi images running RetroPie. So yes, please post any images from an HD monitor or TV for a similar comparison of apples to apples screenshots with GPU enabled off.

Anyway he's shared example pics, exact target dimensions, multiplier, overclock and shader states. He's shared everything you need to reproduce the error in his example. I was just trying to help out in posting other examples of games with similar issues and @UDb23 created another test BD for us to use.

I guess we'll just agree to disagree. I'll leave it to you whether you want to help @UDb23 so he may continue to creating HD backdrops, which are fantastic. Ultimately he's the one that needs to decide if they look HD "satisfactory" with your suggested settings above and continue his work.

Sorry, we go around and around about nothing when you don't feel like helping and I've seen you incredibly helpful too. I guess it's just your mood and the day. I've always been a huge fan of @UDb23's work so I want to help out but you clearly have the answer that will make a 512x448 image backdrop look HD clear.

If you ever have used Photoshop you can't upscale an image that small to HD resolution and have HD clarity without some serious work with filter effects and general "photoshopping" of the image. It was a test image and never meant to look HD clear.

I just refuse to get into an argument with you about semantics when the issue has already been clearly stated and documented.

[ghost]

im not arguing at all just dont see any bluring can you point it out. when you start the game game over flashes on and off that why the screen shot might have been a miss match not sure. I did have b linear filtering on. here is shots with bi-lin on and off as well as well as a zip with them all.

original artwork file

bi-lin off

bi lin on

gpu screenshot enable off taken between game over flashes

ed151b46f3379bbde22252616e5d76ff bi-lin_off.png 09743e2d1cffafe53558c84c0ce6c1b7 bi-lin_on.png 5c0caf7ea2806628ad7eb91f0d886746 boottest.png 4e9f1d0baaf38d2056c498a752ec4a89 gpuenableoff.png

md5sums for images looks like i did post the wrong one above. all zipped up so you can check them locally.

If you see blurring can you point it out thanks

[ghost]

screenshots.zip

forgot the zips

fyi i downloaded the gpuenable test above you said was an identical crc its not

5c0caf7ea2806628ad7eb91f0d886746 boottest.png 49c15e2dc1aa29b3efacf2442aa60df4 md5test.png

[ghost]

hopefully thats all the points above dealt with if we made progress on the blurring..... the next step is to find out why it isint working like space invaders did. We cant move on unil the blurring is dealt with though.