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

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

[Pyjamarama]

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 1080

and 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/VVX6

The 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

[dankcushions]

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

[Pyjamarama]

You r right! Excellent result! Kudos!

[RumblinBuffalo]

@dankcushions

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?

[dankcushions]

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!

[dankcushions]

@RumblinBuffalo said in crt-pi shader users - reduce scaling artifacts in lr-mame2003/lr-fbalpha (horizontal AND vertical games):

@dankcushions

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!

[dankcushions]

another bug!! this time with the vertical games. sorry :( updated the files AGAIN! i'll need to update my pacman calculations/image above, also.