Backdrops in mame2003-plus
-
you artwork res multiplier should be 1
your vector res should be 3 or 2 at least
-
@grant2258 - Check and check.
Resolution multiplier (Restart core)
is set to 1 under Settings -> Video.Vector settings used:
mame2003-plus_vector_antialias = "enabled" mame2003-plus_vector_beam_width = "1" mame2003-plus_vector_flicker = "20" mame2003-plus_vector_intensity = "1.5" mame2003-plus_vector_resolution_multiplier = "3" mame2003-plus_vector_translucency = "enabled"
-
@Clyde said in Backdrops in mame2003-plus:
If the vectors become white in the near future thanks to @markwkidd, I think I'll prefer the uv version.
(If you rebuild from source now you will have white vectors.)
-
@Riverstorm What version of ADVmame are you using ? 3.9 provided good res but had performance issues.
-
@Clyde said in Backdrops in mame2003-plus:
@UDb23 Your zip file works fine on my Retropie. See for yourself:
crt or vector shaders are a good example of why backgrounds ultimately will need to be implemented in retroarch rather than the core.
the shader in the above screenshot applies to the whole image (including background) but on the real machine it would only affect the projected graphics. you wouldn’t get any scanlines on the backround art.
if it was done via retroarch and not the core, retroarch could potentially apply the shader to the right part, not the whole image.
-
@Riverstorm the only setting you need to play with from above is your beam width form the settings above.
Ill test the aspect ratio core provided changes we done and check if this caused it to happen vector games as its not a 1:1 anymore from the original hardware point of view. I dont think it that though the only way i can get mine to look like yours is using the default 1x scale. x3 and im good to go on my tv and monitor
-
@Riverstorm said in Backdrops in mame2003-plus:
@Clyde - Damn, you're snaps are sharp! What type of monitor are you using? I can get AdvMAME to look that good but still no dice on Plus.
Maybe it is the shader "VecX" that I don't remember where I got it from? (It was some Retropie/Retroarch shader repo on Github I think.) I can test how it looks without the shader when I get home.
My monitor is an 21" TFT with native 1600x1200. It is connected to the Pi's HDMI port with an HDMI-to-DVI adapter. I can look up the model at home.
I could also show you my
retroarch.cfg
later. -
@Clyde this one's for you:
UV without the yellow "top part" ;-)
Available in same folder as previous.
-
@UDb23 You're just too good for this world. 😱 Thanks! Now I have three backdrops to choose from …
@markwkidd Thanks to you, too. I now have white vectors. Interestingly (as logically), the whole picture lost its yellowish tint, which is a new but not bad impression.
@Riverstorm My monitor is a NEC MultiSync LCD2170NX. And I have a theory about my shader. It may be not downloaded, but saved by RetroArch when I tested some Vectrex games. Seems like RA saves its core and game presets in
/home/pi/.config/retroarch/shaders/presets
, as there is now a/opt/retropie/configs/all/retroarch/shaders/presets/MAME 2003-Plus/omegrace.glslp
that I definitely did not put there.Here's the content of my
VecX.glslp
, if you want to try it to get "my" picture.shaders = "1" shader0 = "/home/pi/.config/retroarch/shaders/stock.glsl" filter_linear0 = "true" wrap_mode0 = "clamp_to_border" mipmap_input0 = "false" alias0 = "" float_framebuffer0 = "false" srgb_framebuffer0 = "false" textures = "iqLUT;scanLUT" iqLUT = "/opt/retropie/configs/all/retroarch/shaders/ghogan42/zfast_res/iqLUT.png" iqLUT_linear = "false" iqLUT_wrap_mode = "clamp_to_border" iqLUT_mipmap = "false" scanLUT = "/opt/retropie/configs/all/retroarch/shaders/ghogan42/zfast_res/scanLUT.png" scanLUT_linear = "false" scanLUT_wrap_mode = "clamp_to_border" scanLUT_mipmap = "false"
So, it uses the normal
stock.glsl
shader. Why it also uses some of @ghogan42's shader resources, I don't know.And here's my complete
retroarch.cfg
if you want to rummage through it for more video options. Why it saysvideo_shader = "~/.config/retroarch/shaders/presets/MAME 2010/MAME 2010.glslp"
I don't know either, as I don't use this shader. -
@Clyde - Thanks for all the setup information. I'll see if I can figure what is causing the issue. I have the basics correct I am sure of it as there's just not much there to configure. In fact I went to 1 on beam width as it looks better on the TV. I tried TATE mode too as per Grant's suggestion on Tempest but still a no go but it was cool to see a 65" game board. Anyway It does look fine until I play AdvMAME (or see your screenshots - I'm coming for the NEC Multisync! ;).
@UDb23 - Thanks for the new BD. I spent a good deal of time last night and I lean toward the UV I think, it's very deja-vu. It's great to have options to make it fresh.
Also the BD's seem to work out of the box with no modifications in AdvMAME. I am running 3.8. What type of performance issues are you seeing in 3.9? I see only 3.9 is available for install under the RP setup. That could throw a wrench in the fray if we are forced to use 3.9 as 3.8 has been working great for me with vector games and BD's.
It seems AdvMAME is the same as 2003 in that the "effects" are applied to both the game area and BD. Since AdvMAME is currently being developed maybe he chose to do it that way purposely?
-
@Riverstorm said in Backdrops in mame2003-plus:
work out of the box with no modifications in AdvMAME. I am running 3.8.
I'm (pleasantly) surprised that they work in 3.8. Multiple tests to make it work correctly in the past failed.
Will try 3.8 again and compare vector quality with 2003plus.
Slowdowns are reported for 3.9 w artwork but I haven't tested myself (actually I don't know how to "manually install it). -
@UDb23 - Yes I remember messing with SI to no avail. :) I'll give you the short version here real quick as it took me a while comparing the original with what's on screen.
In 3.8 Omega Race works with all BD's but it crops to the game area and leaves slight black edges on either side but it's fine vertically. I had to look several times to see what it was doing. For contrast if you play it on AdvMAME 1.4 the BD stretches the original BD cropped game area as well as the game itself. Making both game and BD to wide.
In 3.8 SI it's pretty much the same. It crops the left and right to the game area only. In AdvMAME 1.4 it stretches that original game area as well as the game to fill the screen. Way to wide for 3:4 games.
It's not immediately noticeable on 4:3 games and looks great actually. So some improved scaling is happening as the original cockpit resolution is huge but it looks good with the little left/right cropping that is going on. Basically it scales the BD to game area but also does a little cropping. It's hard to explain and weird but looks good. 3:4 games on the other hand are an immediate give away.
So 4:3 look good and 3:4 not so much. You can check it out but I think I would use them for 4:3 games for me as yours are so much nicer but 3:4 just don't look right unless it's SI only, that game.
Here's something weird when I play on a TV I suffer no performance issues (100% on speed--F11) but when I played on the 1920 x 1200 monitor with the speed on screen it dipped down to 75% and lower and performance suffered noticeably several times. I have no idea why as the resolution isn't that much different. Also maybe worth noting is it didn't matter whether it was the 1-2MB star BD or the full size 6MB cockpit BD it ran full speed on the TV.
-
@UDb23 - Here's a screenshot as it might be easier than explaining. Click it to zoom full size. It's yellow tint due to AdvMAME. If you start the game and just play it looks good actually. I can't get Plus vectors looking that nice.
I think Clyde has a different monitor and shader that might make a difference but I wonder if @grant2258 or someone with a Pi would post a screenshot of Omega Race for comparison (it doesn't need the background) without a shader to see the vector lines. As of now I only have what I see on my screen for comparison. The shots posted above by Grant have been degraded to much for upload so all the detail is lost.
-
@Riverstorm I tested a bit more with the different settings for beam width (BW) and vector multiplier (VM). Here are the results: https://imgur.com/a/nntJwhJ
It's rather obvious that the VM has a heavy impact on the quality of both the beams as the backdrop. Maybe your VM is too low? But I also noticed that a higher VM puts more strain on the game's speed and jerkiness. On my system (Pi 3B without "+", not overclocked), VM 3 has the best balance between picture quality and performance in my opinion.
That said, modern TVs are infamous for messing with the picture and/or responsiveness of games. Not without reason, there is a section about speed issues with TVs in the Retropie Docs, and some more tips regarding TVs in the FAQ. I can't help you more with that, because I don't have a TV for more than 10 years now.
What I don't understand is why my monitor should have any impact on the quality of my screenshots, since I make them from within RetroArch and not as photos from my monitor screen. Furthermore, I have disabled EDID via a line
hdmi_ignore_edid=0xa5000080
in my/boot/config.txt
because I had issues with the HDMI splitter that I use to mirror my cabinet's picture on my video projector. So as I understand it, my Pi shouldn't even know what monitor it is connected to.As for my Omega Race (OR), I now decided to use @UDb23's UV2 backdrop at 0.30 brightness. Even with white vectors, I like it a bit more than the UV version with yellow elements. I also shrunk the game area to 1400x1050 (the next common 4:3 resolution below 1600x1200), because the original OR machines also had a smaller game area than their backdrop, as you can see on the video and the image posted by me and @UDb23.
My beam width remains 2 and my vector multiplier is still 3.
You can see the result here: https://imgur.com/JeE2aqs (A link to Imgur, because I want to reduce my image-spamming here ab bit. 😇 )
edit: typo
-
the screenshots arent degraded they where taken on a laptop 720p with a 1x res. I dont use vector games much what seeting you want the screenshot taken with on the pi?
-
@Clyde - Your answers are well written and helpful, thanks. I was referring mainly to the shader altering the frame and not so much the display, except the final output might look nicer on that old NEC Multisync.
I haven't heard that name (NEC) in years. One of my first PC monitors was a company named Packard Bell beyond that the old Tandy line from Radio Shack. Before that the old VIC-20 and 64. Anyway thinking I guess you're using RA so your snaps are "true" to what's generated.
The one area I haven't put time into is my TV and you have given me another avenue to explore. Let me check it's settings for a game mode and other processing but also at the back of my thoughts AdvMAME does look correct but I have hope that something here might be the cause.
I had wondered before about it and glad others do too. Here's my take on it. Beyond a small information exchange (between the TV and Pi--like mode and resolution) the Pi has no idea what "post frame processing" the TV is doing like upscaling, smoothing, color, tint, etc. It also has no information on the pixels dimensions like square or rectangular. If you used h/v sync to stretch or compress an image, etc. A lot of things can happen once it hits the display that the Pi basically has no control over.
So basically screenshots in RA are exactly how the Pi processes them before they even get sent to the TV and then the TV further processes them. I think what we see on screen and how frames are generated are slightly different in appearance.
You could take a RA generated screenshot and actual TV/monitor photo to see the differences.
AdvMAME is that way. It takes the screenshot before any filter effects are applied. Step 1 - generate frame, Step 2 - apply filter effects, Step 3 - send frame to tv.
AdvMAME takes the screenshot between steps 1 and 2 whereas RA between 2 and 3.
I duplicated your all your settings except I made my beam width 1 vs 2. Two looks to wide on my HD TV. The comparison shot above was with a BW of 1.
Since you removed that "feature" do you specify every games resolution manually?
You have given me some good information to work with thank you.
Wow, no TV for 10 years, that's impressive. The TV was like a surrogate parent for me growing up. Even when I don't watch it I have it on for the background noise. I think better with it on or as my wife says; I'm wasting electricity.
-
retroarch has two ways of taking a screen shot go to video->settings
gpu enable screenshot. You really shouldnt limit yourself to retropie when testing install in on windows or linux youll have access to more driver choices
-
One of the other downsides of not having backdrop artwork support in RetroArch yet is that there is another layer of scaling introduced. Because vector rendering also happens within the core and depends on resolution upscaling to look good on a digital that is another layer of scaling.
That means you have scaling potentially happening four times:
- vector rendering in the core
- artwork rendering in the core
- video rendering in the frontend (retroarch in this case)
- television rendering the signal
People on the same emulator platform should be able to synchronize their settings for the first three and produce identical screenshots. However to get good results across a variety of connection types and displays might require trial and error changes to settings for the first three layers -- if that makes any sense.
-
I dont think the artwork is anything to do with it in this case. Does your rendering improve when you disable the artwork if not is scaling somewhere between the tv or the gpu. Im not sure how retropie deals with overscan ect.
for lg i get my scaling working properly for 90% of things by picking aspect ratio-> just scan form the quick menu
-
not really sure what good it will do posting screenshots from the pi but here you go
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.