crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come)
-
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.
-
preference order:
only within a certain tolerance of the original aspect ratio? but maybe harder to code. If a vertical game is only -1% stretched with today script there is a chance we got a +10% only with round up. (I dont know if there is games with range between -1 to -3%
only for vertical games?
always round up the x scale in horizontal/vertical games?
-
this works fabulously on my pi3 and 1280x1024 - thank you very much! :):)
-
@garion @caver01
ok, i made a set of 'wider' configs that prioritise a wider aspect ratio, as long as it's within 25% tolerance from the game's original aspect ratio.crt-pi_mame2003_configs_1920x1080.zip
crt-pi_mame2003_configs_1280x720.zip
crt-pi_mame2003_configs_1280x1024.zipcrt-pi_fbalpha_configs_1920x1080.zip
crt-pi_fbalpha_configs_1280x720.zip
crt-pi_fbalpha_configs_1280x1024.zip25% is the minimum it would have to be to allow widening in @caver01's 'krull' example. i'm not sure how much of a change it makes for other games. maybe the tolerance can be higher. does anyone else have any examples of games that look like they should be wider, using these or my previous configs?
not tested any of these yet, but will do tonight :)
-
@dankcushions P-E-R-F-E-C-T
tested:
donpachi
ddopach
ddpoj
espalluga
esprade
reversos
progear (horiz)
sailormoon (horiz)great visual improvement in vertical games.
thanks for your update.
-
I'm curious, can the exact same principles used here for the MAME configs, be used for the other 4:3 systems (Genesis etc.) to reduce banding effects? For example, I've seen some of the rainbow/banding effect here and there testing certain Genesis/NES games, with the CRT-PI shader on (default settings - core aspect ratio etc.)
If I turn on integer scaling, of course these go away and with it my screen shrinks (bars top/bottom). However - if I change my aspect ratio to custom I can adjust the aspect ratio parameters to make it "close" to what it should be (the height of the screen, but slightly wider or narrower, much like MAME).
I only tested a couple of ROMS. and it seems to work fine for NES, SNES, but for the Genesis/Megadrive I notice the top/bottom of the screen cuts off a few lines.
I'm still learning, but is it possible that one could edit the retroarch config for a specific system (Genesis for example) and set the integer scale parameters (custom) to eliminate the banding effects? The trade off being that the games play slightly wider, but cleaner?
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.