crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come)

[vbs]

@dankcushions
Should the crt-pi-vertical maybe added to the "official" shader collection here https://github.com/RetroPie/common-shaders?

EDIT:
Oh also would it make sense to have two additional crt-pi-curvatureand crt-pi-vertical-curvature?

[dankcushions]

@vbs said in crt-pi shader users - automatic usage of crt-pi-vertical in vertical games in lr-mame2003:

@dankcushions
Should the crt-pi-vertical maybe added to the "official" shader collection here https://github.com/RetroPie/common-shaders?

EDIT:
Oh also would it make sense to have two additional crt-pi-curvatureand crt-pi-vertical-curvature?

it is :) see https://github.com/RetroPie/common-shaders/tree/rpi

(on the rpi branch)

[vbs]

@dankcushions
Oh I see, I didn't know that there is a separate branch for rpi. I am on x86 so probably on x86 the master branch is used and thats the reason I don't have it? Should I make a PR to add those shaders also on master or is it intended to not be there?

[dankcushions]

@vbs there's no harm in it but if you're on x86 you will probably want to use a more sophisticated crt shader.

[windale]

@dankcushions
Are your new 'crt-pi-vertical' and 'crt-pi-vertical-curvature' shaders still in progress or have they already been changed ?

[dankcushions]

@windale said in crt-pi shader users - automatic usage of crt-pi-vertical in vertical games in lr-mame2003:

@dankcushions
Are your new 'crt-pi-vertical' and 'crt-pi-vertical-curvature' shaders still in progress or have they already been changed ?

i have not/am not doing any changes to the shaders. i have done some changes to per-game mame/fba configs to do better shader scaling, which i will release when i'm happy with them.

[windale]

@dankcushions That's OK, i've decided to go with no shader and no filter because i've seen scrolling stuttering in Genesis games with the CRT filter, so MAME games will run even worse. I'm starting to quite like the pixelated look !

[caver01]

@dankcushions Are these changes merely adding integer scaling or are there tweaks to brightness or something too? Your second closeup looks like it has more color saturation. Is that true?

[dankcushions]

@caver01 said in crt-pi shader users - automatic usage of crt-pi-vertical in vertical games in lr-mame2003:

@dankcushions Are these changes merely adding integer scaling or are there tweaks to brightness or something too? Your second closeup looks like it has more color saturation. Is that true?

neither :) it's using smarter scaling without adding borders (like integer can).

[dankcushions]

been a long time coming, but i've finally finished my script! i have now generated cfgs that reduce CRT shader artifacts in vertical AND horizontal games. it's quite striking IMO.

i've updated the original post with the details. you can see the python script if you want here: https://github.com/dankcushions/crt-pi-configs/blob/master/crt-pi-configs.py

[caver01]

@dankcushions This is cool. So, I know the script is generating configs, but I want to understand the logic behind the result. Correct me if I have this wrong, but in addition to setting the crt-pi-vertical.glslp, you are using integer scaling on the X-axis to get as close as possible to the best fit of the game within a given display. . . then, you are setting the y resolution to the display's Y resolution? (of course, you are also specifying the properly calculated viewport)

1. Because it's a vertical game going into a horizontal display, if you want it oriented correctly (and not stretched ridiculously wide) you are always going to have borders on the sides.
2. Integer scaling eliminates shader artifacts, but crucially, these artifacts are primarily noticeable across the X-axis, and not as much in the Y.
3. You scale the game to an integer value on the X, then stretch to fit into the screen on the Y.
4. You end up with a slightly imperfect aspect ratio, but it's a tradeoff--by allowing a nearly imperceptible amount of stretch in the vertical dimension, you avoid black bars on the top and bottom, effectively fitting into the display, but without the rainbow artifacts.

Do I have it right? If so, that's clever! I can live with a slightly incorrect AR. Now, I wonder how bad it gets with curvature enabled?

Could we get a set of configs for 1280x1024?

For me, there are only a handful of games that I rotate like this (most vertical games run in TATE mode). But for those where this applies (side-by-side controls, trackball, etc) I am wondering: are you always stretching into Y resolution, or sometimes compressing, if the closest X integer happens to be slightly bigger than the vertical with the correct AR?

[dankcushions]

@caver01 yes you have it exactly :) for horizontal games the improvement is not so obvious, but for me the aspect ratio change is so slight that i don't see why not.

Now, I wonder how bad it gets with curvature enabled?

i don't use it, but i would guess since curvature is distorting the image away from the normal pixels already, having it integer scaled probably doesn't make a difference. you probably just want the highest resolution possible.

Could we get a set of configs for 1280x1024?

sure! just added them to the first post :) i haven't tested these but they should work properly.

For me, there are only a handful of games that I rotate like this (most vertical games run in TATE mode). But for those where this applies (side-by-side controls, trackball, etc) I am wondering: are always stretching into Y resolution, or if you are sometimes compressing, if the closest X integer happens to be slightly bigger than the vertical with the correct AR?

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.

[dankcushions]

forgot to mention! Special thanks to @UDb23 who created the resolution_db that my script uses to figure out the right scaling.

[caver01]

@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.

[caver01]

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?

[dankcushions]

@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.

[Dochartaigh]

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?

[dankcushions]

@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.

[caver01]

@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.

[dankcushions]

@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.