crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come)
-
@dankcushions said in [crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha \
if i'm understanding the question right, with these CFGs the Y resolution is always to the full height of your screen. all i have to worry about is that my integer scale on the X side is as close to the proper AR as possible.
I get that the Y is always an exact match to the display. The question is more about how the X is calculated. I'd have to look at the resolution db to find a good example, but it strikes me as possible that an integer scale could be closer to the display (but bigger) than the next integer down (that fits inside) such that you get less AR distortion by shrinking the Y value to the display size instead of a lower integer that requires you to stretch the height.
-
Another way to say it is this: Are your X calculations always smaller (or fitting within) the given display resolution, or are you taking the closest integer, even if the result would be taller than the display?
-
@caver01 said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
Another way to say it is this: Are your X calculations always smaller (or fitting within) the given display resolution, or are you taking the closest integer, even if the result would be taller than the display?
the X calculations would make it wider/narrower, not taller. not sure i understand :)
maybe this helps: when i'm working out what X scale to use, i don't just use the first one before it gets greater than the target aspect ratio, i calculate a bunch and then use the closest one to the target.
this means that if you were using that same scale on the Y axis (which i'm not - i'm stretching to fit), it maight actually be greater than your display resolution and go over the top/bottom, but for our purposes it would still be the closer X scale to use.
-
So you all are speaking French to me ;) (no offense to the French!), so how would I go about updating to the new CRT-Pi shader? I'm assuming jut updating from source won't do it...?
Do I update my CRT-Pi.glslp or .glsl files I've tweaked settings in before with that new code?
-
@Dochartaigh said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
So you all are speaking French to me ;) (no offense to the French!), so how would I go about updating to the new CRT-Pi shader? I'm assuming jut updating from source won't do it...?
Do I update my CRT-Pi.glslp or .glsl files I've tweaked settings in before with that new code?
i've not updated the shader at all. this is just configuration files that adjust the screen resolution so the shader is more effective. i'm not sure what version of retropie included the shader and the version of retroarch that supports overrides, but 4.1 and up should be definitely ok.
-
@dankcushions Here's what I mean:
Say you are scaling a vertical game that runs natively at 224x288 (AR=.77) for a display that is 1920x1080.
Option 1: Scale to 3x you get 672x864, and you stretch Y, so: 672x1080 (AR=.62)
This option has some vertical stretch to overcome the 216 pixels shy of 1080.Option 2: Scale to 4x you get 896x1152, and you compress Y so: 896x1080 (AR=.82)
This option has some vertical compression (or horizontal stretch if you want to say it that way) because you have to overcome only 72 pixels of vertical overage.Option 2 has less distortion than option 1 (assuming square pixels are desired).
Now that I have this example, it strikes me that on real arcade CRTs, the game might have been adjusted to fill the screen, so the goal would be to find the x-integer that lands you as close to 4:3 as possible, with Y scaled up or down to match the display resolution.
-
@caver01 said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):
@dankcushions Here's what I mean:
Say you are scaling a vertical game that runs natively at 224x288 (AR=.77) for a display that is 1920x1080.
Option 1: Scale to 3x you get 672x864, and you stretch Y, so: 672x1080 (AR=.62)
This option has some vertical stretch to overcome the 216 pixels shy of 1080.Option 2: Scale to 4x you get 896x1152, and you compress Y so: 896x1080 (AR=.82)
This option has some vertical compression (or horizontal stretch if you want to say it that way) because you have to overcome only 72 pixels of vertical overage.Option 2 has less distortion than option one (assuming square pixels are desired).
my script would use option 2 here, because the aspect ratio (.82) is closest to the native one (.77)
Now that I have this example, it strikes me that on real arcade CRTs, the game might have been adjusted to fill the screen, so the goal would be to find the x-integer that lands you as close to 4:3 as possible, with Y scaled up or down to match the display resolution.
yeah i use the actual aspect ratios of the displays that these games ran on (which has been collated by @UDb23 here) in my calculations. eg, for a CPS2 game I would target the DAR of 4:3, rather than the PAR, which is closer to widescreen. almost all arcade games are really 4:3 or 3:4.
-
Thank you @dankcushions for your work!!
I have an issue thought. The vertical games in MAME2003 (I haven't tested FBAyet)are very very narrow. I am using a quite new Samsung 1080p TV.
I pasted inside my PetroPie mame roms and executed
python crt-pi-configs.py mame2003 1920 1080and too the folder to /opt/retropie/configs/all/retroarch/config/
http://www.ultraimg.com/image/VVX3
I was checking the config
# Place in /opt/retropie/configs/all/retroarch/config/MAME 2003/ 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 = "224" custom_viewport_height = "1080" custom_viewport_x = "848" custom_viewport_y = "0"The display does seem to be 224 * 1080...very spaghetti...surely not correct
Horizontal games got a lot prettier but I miss things on top and bottom
http://www.ultraimg.com/image/VVX6The config is again a bit strange (1200?)
# Place in /opt/retropie/configs/all/retroarch/config/MAME 2003/ video_shader_enable = "true" video_shader = "/opt/retropie/configs/all/retroarch/shaders/crt-pi.glslp" # To avoid horizontal rainbow artefacts, use integer scaling for the width aspect_ratio_index = "22" custom_viewport_width = "1920" custom_viewport_height = "1200" custom_viewport_x = "0" custom_viewport_y = "-60"Any help appreciated
-
@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.
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.