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

[Rion]

@dankcushions Ok i will update my posts with the cfg files during the evening.

[Floob]

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

i see, the shader location has changed in 4.1. i will update my .cfgs.

still, unless someone can give me a good reason for keeping the .zip.cfg versions, i will be cleaning up this thread

Is there a chance someone not on a new enough version of RetroArch will get confused why the retroarch based location/overrides dont work?
Although I would hope as more and more people use the current version of RetroPie/RetroArch it shouldnt matter.

[Rion]

@dankcushions Sorry about the delay. Here are the fixed ones for RetroPie 4.1 *.cfg Only

mame2003_Vertical_ crt-pi-vertical

mame2003_Vertical_crt-pi-curvature-vertical

These should go into the folder "/opt/retropie/configs/all/retroarch/config/MAME 2003/" or and not the rom folder.

Please tell me if i misses anything?

[dankcushions]

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

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

i see, the shader location has changed in 4.1. i will update my .cfgs.

still, unless someone can give me a good reason for keeping the .zip.cfg versions, i will be cleaning up this thread

Is there a chance someone not on a new enough version of RetroArch will get confused why the retroarch based location/overrides dont work?
Although I would hope as more and more people use the current version of RetroPie/RetroArch it shouldnt matter.

i thought about this but the vertical shader was only included in retropie from 4.0 ish, and RA overrides were late august, so hopefully it shouldn't be a problem for many. hopefully!

[dankcushions]

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

@dankcushions Sorry about the delay. Here are the fixed ones for RetroPie 4.1 *.cfg Only

mame2003_Vertical_ crt-pi-vertical

mame2003_Vertical_crt-pi-curvature-vertical

These should go into the folder "/opt/retropie/configs/all/retroarch/config/MAME 2003/" or and not the rom folder.

Please tell me if i misses anything?

looks good to me, thanks! i can test later.

[dankcushions]

sorry, got a bit sidetracked :) i have been working on a small improvement to my .cfgs.

previous with crt-pi-vertical.glslp:

now:

this is via my new resizing algorithm that always keeps the horizontal scaling at an integer scale, but still stretches the vertical to fullscreen. this makes things look a lot better when using vertical scanlines, especially when scrolling left to right. i think this sort of algorithm will be goof for horizontal games also, but i need to test.

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