crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come)
-
@Pyjamarama said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
why did you run the script? i already generated the cfgs for 1080p. i suggest using the ones i generated first, then let me know if there's still a problem.
-
You r right! Excellent result! Kudos!
-
Appreciate your efforts and updates/postings. Lots of educational reading here - trying to keep up.
On a fresh RetroPie 4.1 setup, I've read and followed everything above and have placed the .cfg files into the \Mame 2003\ folder and they are working as advertised. I can see the override is enabled and the vertical shader is being used.
However, I am not 100% certain with regards to the scaling. Using the pacman, dkong etc. as an example, on my display (1920x1080) the game fills the screen vertically, but appears to stretch maybe 10%-15% wider than the "core provided" ratio (which I believe is 3:4). Is this by design (a result of the script that generates the scale), or have I missed a setting someplace that would allow me to retain the core aspect ratio?
I know you've discussed the scaling being slightly inaccurate above but this seems greater than what you've discussed above?
-
All - I noticed a bug in my last set of cfgs and have updated them! There was some incorrect ratios used. Please re-download, sorry!
-
@RumblinBuffalo said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
Appreciate your efforts and updates/postings. Lots of educational reading here - trying to keep up.
On a fresh RetroPie 4.1 setup, I've read and followed everything above and have placed the .cfg files into the \Mame 2003\ folder and they are working as advertised. I can see the override is enabled and the vertical shader is being used.
However, I am not 100% certain with regards to the scaling. Using the pacman, dkong etc. as an example, on my display (1920x1080) the game fills the screen vertically, but appears to stretch maybe 10%-15% wider than the "core provided" ratio (which I believe is 3:4). Is this by design (a result of the script that generates the scale), or have I missed a setting someplace that would allow me to retain the core aspect ratio?
I know you've discussed the scaling being slightly inaccurate above but this seems greater than what you've discussed above?
Hmm, this might be related to the bug I just fixed, so please re-download the files. Here is what pacman looks like at the moment:
The resolution is 896x1080, which is a 0.83 ratio. Compare that to the actual ratio, which is 3:4 (0.75) and it's pretty close. 10-15% wider (or narrow) is probably about right for most cases.
bear in mind that my algorithm tries to get the closest integer scaling on one axis, so it will rarely be at the exact proper aspect ratio, but it will have no horrible scaling artefacts along that axis.
EDIT: updated image and calculation due to silly bug!
-
another bug!! this time with the vertical games. sorry :( updated the files AGAIN! i'll need to update my pacman calculations/image above, also.
-
@dankcushions I know it must be tedious to regenerate and re-up the files, but I think your clever insight about how integer scaling on a single dimension is all you need to clean up the artifacts is worth the 'bump' to give this post more visibility!
-
@caver01 thanks :) it's not quite perfect - you'll still get banding with vertically scrolling games/backgrounds. eg, the intro to street fighter II. however, to eliminate those you've no choice but full integer scaling, with top/bottom borders, and you don't need my configs for that :)
it'll be nice when 4k is the standard:
- 240 (common CRT height) divides exactly into 2160
- 224 (another one) x 9 = 2016 leaves only a 7% border
compared to 1080p
- 240 x 4 = 960, 12% border
- 224 * 4 = 896, 17% border
-
@dankcushions Ouch. Yeah, those borders are why I never bothered with integer scaling, but I have been meaning to sit down with my system and try some of your configs. As a standalone arcade build, I can't imagine having a spare 4K display to mount inside my expensive "toy", but it will be better for what is probably the majority of folks running RetroPie on their TVs. However, at that resolution, perhaps the artifacts become less noticeable?
-
Thanks for the info/screenshot. That matches up with what I am seeing so it appears I've set this up properly (and would explain the 9% wider image). Really appreciate the example!
So if I understand correctly, applying the crt-pi vertical shader to a screen set at the proper aspect ratio (in this case, pacman @ 3:4), the difference would be a reduction in quality of the shader (I should see scaling artifacts)?
One more oddity - i've also tested/ setup a couple of .37b5 roms using mame-libretro (2000) using the regular crt-pi shader (horizontal). I've noticed the regular crt-pi shader on these appear to look quite good on a vertical game (mspacman). Strangely, if I switch the to the vertical shader, the quality suffers/banding effect returns. This seems to be "opposite" of how it should work. Is there any reason why the standard crt-pi shader would look "correct" using the older MAME core?
-
all working fine with cfg in MAME 2003 and FB Alpha but I notice some strange aspect ratio in well known games. By example Do donachi and others vertical games.
@dankcushions I use the your zip file in first post.
if 720 width then vertical games looks stretched. 896 seems perfect.
EDIT2: I look into the crt-pi-configs DB and:
ddpdoj, 448, 224,V,R, 810, 1080, 672, 896, 3, 4
ddonpach, 320, 240,V,R, 810, 1080, 720, 960, 3, 4
ddonpachj, 320, 240,V,R, 810, 1080, 720, 960, 3, 4Maybe I´m in a visual mistake.
DDONPACHJ
aspect_ratio_index = "22"
custom_viewport_width = "720"
custom_viewport_height = "1080"
custom_viewport_x = "600"
custom_viewport_y = "0"DDPDOJ
aspect_ratio_index = "22"
custom_viewport_width = "896"
custom_viewport_height = "1080"
custom_viewport_x = "512"
custom_viewport_y = "0"EDIT3: I use the script with FBA with 1920x1080 and get that with same game and results are not the same than in the zip-cfg- file:
DDPDOJ
aspect_ratio_index = "22"
custom_viewport_width = "448"
custom_viewport_height = "1080"
custom_viewport_x = "736"
custom_viewport_y = "0"EDIT4: with above config DDPDOJ looks spaguettized.
-
@RumblinBuffalo said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
Thanks for the info/screenshot. That matches up with what I am seeing so it appears I've set this up properly (and would explain the 9% wider image). Really appreciate the example!
So if I understand correctly, applying the crt-pi vertical shader to a screen set at the proper aspect ratio (in this case, pacman @ 3:4), the difference would be a reduction in quality of the shader (I should see scaling artifacts)?
yes :) you might not necessarily see the scaling artifacts (especially on a game with a static dark background like pacman), but they are there.
One more oddity - i've also tested/ setup a couple of .37b5 roms using mame-libretro (2000) using the regular crt-pi shader (horizontal). I've noticed the regular crt-pi shader on these appear to look quite good on a vertical game (mspacman). Strangely, if I switch the to the vertical shader, the quality suffers/banding effect returns. This seems to be "opposite" of how it should work. Is there any reason why the standard crt-pi shader would look "correct" using the older MAME core?
the core must tell the api that this is a rotated game. i'm not so sure that mame2000 does this. i only work with mame2003 really.
-
@garion said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
all working fine with cfg in MAME 2003 and FB Alpha but I notice some strange aspect ratio in well known games. By example Do donachi and others vertical games.
@dankcushions I use the your zip file in first post.
if 720 width then vertical games looks stretched. 896 seems perfect.
EDIT2: I look into the crt-pi-configs DB and:
ddpdoj, 448, 224,V,R, 810, 1080, 672, 896, 3, 4
ddonpach, 320, 240,V,R, 810, 1080, 720, 960, 3, 4
ddonpachj, 320, 240,V,R, 810, 1080, 720, 960, 3, 4Maybe I´m in a visual mistake.
DDONPACHJ
aspect_ratio_index = "22"
custom_viewport_width = "720"
custom_viewport_height = "1080"
custom_viewport_x = "600"
custom_viewport_y = "0"with this game, the native aspect ratio is 3/4 (0.75)
the ratio my algorithm generates is 720/1080 (0.66)
the next scale up would by 720+240 = 960
the ratio of THAT would be 960/1080 (0.88)0.66 is closer to 0.75 than 0.88 so that's what it uses. i do agree that i might normally prefer it to be too wide than narrower for vertical games. i've been thinking about maybe always using the next widest scale for vertical games - do others agree?
DDPDOJ
aspect_ratio_index = "22"
custom_viewport_width = "896"
custom_viewport_height = "1080"
custom_viewport_x = "512"
custom_viewport_y = "0"EDIT3: I use the script with FBA with 1920x1080 and get that with same game and results are not the same than in the zip-cfg- file:
DDPDOJ
aspect_ratio_index = "22"
custom_viewport_width = "448"
custom_viewport_height = "1080"
custom_viewport_x = "736"
custom_viewport_y = "0"EDIT4: with above config DDPDOJ looks spaguettized.
i'm not sure why you're getting those results. are you using the latest script? what command are you using to launch it? do you have the latest resolution_db files from my repo?
-
thanks for your quick answer.
Use next widest scale is a good solution with 1080p displays. Today we have very big screens so black bars are really big with 0,66 A/R.
I forgot ask about, how to use curvature with the script? (or downloaded cfgs zipped)
about script. I use last one, downloaded today from GitHub HERE. I unzip it then go to that folder and use:
python crt-pi-configs.py mame2003 1920 1080
and
python crt-pi-configs.py fbalpha 1920 1080
Run script perfect. Each script create new dir with lot of cfg then a zip file.
--
I repeat the script with fbalpha right now and same results.
-
Thanks again for all the help! I do want to mention that the shader looks great on the old school classics (pacman, dkong, etc. that I've tried so far.
yes :) you might not necessarily see the scaling artifacts (especially on a game with a static dark background like pacman), but they are there.
You're right. I was able to test my setup on a larger TV last night and with pacman, I was able to see very slight banding at 3:4 ratio (in the ghosts). It was pretty flawless using your CFG/ratio. I'll probably get a better idea once I look at some different roms.
the core must tell the api that this is a rotated game. i'm not so sure that mame2000 does this. i only work with mame2003 really.
Could be - I'll keep playing with it and see. I've only had an RPi for about 6 months but it sure is a fun little hobby (endless tinkering). I'm also amazed at the amount of creative cabinets/projects/ideas of I've seen already.
-
@dankcushions I am finally getting around to trying these configs. I only have a handful of titles that I run vertical when viewed from the horizontal side of my display. The configs make these games look perfect, but I am finding that for a few of them, I am sizing up to the next integer. I wonder, is anyone else doing that too?
It does require some recalculations on the horizontal (basically, adding the game's horizontal value to the existing custom_viewport_width, and subtracting half of that from the custom_viewport_x).
The reason behind my tinkering can be demonstrated using the game, Krull. This is a vertical game (240x256) which happens to scale perfectly to 960x1024 (my display is 1280x1024), assuming 1:1 PAR. This is an example of a game NOT running at 3:4 AR. The thing is, without a copy of the manual for the original game, we just can't know if manufacturer intended arcade operators to adjust the CRT to fill the image edge to edge, or if they were supposed to preserve a square PAR. I think to err on a typical 3:4 AR is the right rule of thumb, but some games do look better if the target tries to preserve 1:1 pixels.
In any case, running the crt-pi shader should have everyone thinking in terms of X integer scaling on vertical games,
-
@garion said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
thanks for your quick answer.
Use next widest scale is a good solution with 1080p displays. Today we have very big screens so black bars are really big with 0,66 A/R.
agreed - I will address this in my next post :)
I forgot ask about, how to use curvature with the script? (or downloaded cfgs zipped)
my script is not for the curvature shader. since that already distorts the image, as far as i can see there is no point tweaking the X scale. the pixels don't line up in the same way so it wouldn't benefit.
about script. I use last one, downloaded today from GitHub HERE. I unzip it then go to that folder and use:
python crt-pi-configs.py mame2003 1920 1080
and
python crt-pi-configs.py fbalpha 1920 1080
Run script perfect. Each script create new dir with lot of cfg then a zip file.
--
I repeat the script with fbalpha right now and same results.
i can't explain this :( i cleared everything down and ran it with your line above (which is the same as i'd use) and ddpdoj:
# Auto-generated crt-pi-vertical.glslp .cfg # Place in /opt/retropie/configs/all/retroarch/config/FB Alpha/ video_shader_enable = "true" video_shader = "/opt/retropie/configs/all/retroarch/shaders/crt-pi-vertical.glslp" # To avoid horizontal rainbow artefacts, use integer scaling for the width aspect_ratio_index = "22" custom_viewport_width = "896" custom_viewport_height = "1080" custom_viewport_x = "512" custom_viewport_y = "0"as long as the resolution_db files are there it should always make the same results.
-
@caver01 said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
@dankcushions I am finally getting around to trying these configs. I only have a handful of titles that I run vertical when viewed from the horizontal side of my display. The configs make these games look perfect, but I am finding that for a few of them, I am sizing up to the next integer. I wonder, is anyone else doing that too?
yep! you, me and @garion :) i agree sizing up is usually what you want to do, but i'm not sure how to best do it in the script:
- always round up the x scale in horizontal/vertical games?
- only for vertical games?
- only within a certain tolerance of the original aspect ratio?
i think 1. would work with 1080p screens. maybe 720p you'd start getting some ugly stretching (which you possibly already start to get with this script).
It does require some recalculations on the horizontal (basically, adding the game's horizontal value to the existing custom_viewport_width, and subtracting half of that from the custom_viewport_x).
The reason behind my tinkering can be demonstrated using the game, Krull. This is a vertical game (240x256) which happens to scale perfectly to 960x1024 (my display is 1280x1024), assuming 1:1 PAR. This is an example of a game NOT running at 3:4 AR.
The thing is, without a copy of the manual for the original game, we just can't know if manufacturer intended arcade operators to adjust the CRT to fill the image edge to edge, or if they were supposed to preserve a square PAR. I think to err on a typical 3:4 AR is the right rule of thumb, but some games do look better if the target tries to preserve 1:1 pixels.
yeah, definitely! there are some interesting discussions on 'correct' aspect ratios for all sorts of systems on the libetro forums: https://libretro.com/forums/showthread.php?t=1471 (looks like their forum is down at the moment)
-
@dankcushions I have never looked for it, but I wonder if anyone has ever created a document to track intended pixel-aspect-ratios for arcade games. It would probably require citing the original designers/game programmers or owners manuals, and most will be a calculation resulting from filling the display to 4:3, so I doubt anyone has bothered. At some point, it becomes owner's preference, but you can make good arguments for different results. For example, I think we are landing somewhere in the sweet spot of acceptable distortion with scanline and shadow mask shader improvements, but this has to be balanced with things like round helicopter rotors, or round enemy fire vs. ovals. If endlessly configuring your games is not something you love, you are in the wrong hobby!
-
@dankcushions I´ll try tomorrow with another computer and new re-download of the Db.
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.