crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come)
-
@andrewh I may be missing the point reading along here, but I cannot help but notice that it looks like your new method the example doesn't integer scale the width. I thought that was the whole point: You integer scale the width so that you eliminate unsightly CRT-PI shader artifacts, then expand (or contract) the Y dimension to fit the display (whichever offers the least distortion). If you just ignore the integer scaling within a tolerance, why bother?
-
@caver01 said in crt-pi shader users - reduce scaling artifactsbolded text with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
@andrewh I may be missing the point reading along here, but I cannot help but notice that it looks like your new method the example doesn't integer scale the width. I thought that was the whole point: You integer scale the width so that you eliminate unsightly CRT-PI shader artifacts, then expand (or contract) the Y dimension to fit the display (whichever offers the least distortion). If you just ignore the integer scaling within a tolerance, why bother?
Integer scaling of the width is only necessary for vertical games, not horizontal. The new method (like the old one) does integer scaling for vertical games and tries to achieve the best balance of filling the screen and matching the original aspect ratio.
I just posted the examples above because they were relevant to the discussion about Street Fighter 2’s non-square pixels and how they’re treated.
-
@andrewh So it behaves differently with vertical? That makes sense.
-
@andrewh said in 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 with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
If I have three 16:9 monitors and display one is 1280×720, display two is 1600×900 and display three is 1920×1080 (these are real monitor examples). If I program a game that is 100 x 200 pixels using display one it's going to look different on display two and three keeping in mind they are all three 16:9. The difference? The pixel aspect ratio (PAR).
yes - actually this is something neither script does. we don't take into account the aspect ratio of the target screen. we assume they have square pixels. for HDTVs this is almost always right. for PC monitors, yeah... it would be simple to add, though.
For all of those displays, assuming they're advertised as 16:9, then the PAR should be the same for each (i.e. square).
1280 / 720 = 1.77777777777777
1600 / 900 = 1.77777777777777
1920 / 1080 = 1.77777777777777
and
16 / 9 = 1.77777777777777you're right - i didn't bother to do the maths but yes - all of @Riverstorm's displays have the same PAR (1:1).
Back to the earlier point - as Dank points out just above, it's possible to work out the degree of 'stretch' to apply in order to map from a display with one PAR to another. This is what I've done in the latest Pull Request that I submitted to Dank's script a few minutes ago, and interestingly, it gives results a little different, but more 'correct' than previous for some of these cases.
Dank's script currently produces the following output for Street Fighter 2 for a 1920 x 1080 display :
# Auto-generated crt-pi.glslp .cfg # Game Title : sf2 , Width : 384, Height : 224, Aspect : 4:3 # Screen Width : 1920, Screen Height : 1080 # 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 = "1536" custom_viewport_height = "1080" custom_viewport_x = "192" custom_viewport_y = "0"Here's the output using my method (again, SF2 on a 1920 x 1080 screen) :
# Auto-generated crt-pi.glslp .cfg # Game Title : sf2 , Width : 298, Height : 224, Aspect : 4:3 # Screen Width : 1920, Screen Height : 1080 # 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" aspect_ratio_index = "22" custom_viewport_width = "1436" custom_viewport_height = "1080" custom_viewport_x = "242" custom_viewport_y = "0"You'll see that the viewport width in my output is closer to the 1440 manual calculation.
(I've just realised that I'm also showing the 'resampled' game width in the header - 298 vs. the original 384. I can fix this, although it's purely informational and has no bearing on the operation of the script)1436/384 = 3.73
that's not a in integer scale. my script tries to get an integer scale on the X axis for horizontal AND vertical games. i believe i discussed my reasoning for this earlier in the thread, but it is intentional. i could be convinced otherwise, but in my experience at 1080p the difference from the correct ratio is not noticeable. maybe at lower resolutions you'd not want it.
remember that the scaling artefacts are always present in both dimensions, just more noticeable in the axis perpendicular to the scanlines. my "priority of needs" on a 16:9 HDTV is something like:
- no top/bottom borders
- no scanline artefacts
- no scaling artefacts
- as close to correct aspect ratio as possible
but i could be convinced otherwise. are there any horrible examples where the image looks really stretched?
Comparing across the wider range of games, I've managed to preserve a lot of the important stuff - on 1920 x 1080 displays, the vertical games should have the same width as using the original method, but for 1600 x 1200 displays they'll now be more proportional :-)
And in general, it looks like they should fill the screen a little better - I've re-purposed the 'tolerance' variable so that now, if the difference between the viewport width or height is less than that percentage of the original game width or height, we just stretch to fit. This means, that on a 1600 x 1200 display you get the following;New method :
# Auto-generated crt-pi.glslp .cfg # Game Title : sf2 , Width : 298, Height : 224, Aspect : 4:3 # Screen Width : 1600, Screen Height : 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" aspect_ratio_index = "22" custom_viewport_width = "1600" custom_viewport_height = "1200" custom_viewport_x = "0" custom_viewport_y = "0"vs. old method :
# Auto-generated crt-pi.glslp .cfg # Game Title : sf2 , Width : 384, Height : 224, Aspect : 4:3 # Screen Width : 1600, Screen Height : 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 = "1536" custom_viewport_height = "1200" custom_viewport_x = "32" custom_viewport_y = "0"again this is the same x scaling thing as i mentioned before. i guess with a 4:3 display you don't want borders, so i can see how this would be preferable in that situation.
-
@dankcushions said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
remember that the scaling artefacts are always present in both dimensions, just more noticeable in the axis perpendicular to the scanlines. my "priority of needs" on a 16:9 HDTV is something like:
- no top/bottom borders
- no scanline artefacts
- no scaling artefacts
- as close to correct aspect ratio as possible
but i could be convinced otherwise. are there any horrible examples where the image looks really stretched?
At the moment, the most obvious example would be vertical games on 4:3 displays, which, by default, are still getting output at 1120 x 1200 (i.e. almost square)
So, my approach can definitely be adapted to match your priorities, but I think had them ordered a little differently, and I tried to accommodate more than just 16:9 displays, focusing also on getting best results for 5:4 and 4:3 displays;
(the displays I have at hand for testing are 5:4 and 4:3 - resolutions of 1280x1024 and 1600x1200 respectively)- No / minimal borders
- Keep close to original aspect ratio
- No scanline artefacts for vertical games (where they're most evident)
- Minimal scaling artefacts
I think it's pretty apparent that our differing perspectives on the priorities are what bring about the differences.
I've done a fair bit of testing with the output of my script on the screens I have available, and I've been pleased with the results. Using non-integer scaling on horizontal games doesn't appear to introduce any scaling or scanline artefacts that I could readily detect. The screen is well filled for horizontal games, and the display is nicely proportioned for the vertical games.At the end of the day, though, looking at numbers in config files will only get us so far..
If you can spare some time to test my script and give some feedback on your subjective impression of its output, that would be great. I'm open to suggestions for further changes (maybe we can make some selectable options to allow users to better fine-tune it to their particular needs?)
-
@andrewh said in 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 with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
remember that the scaling artefacts are always present in both dimensions, just more noticeable in the axis perpendicular to the scanlines. my "priority of needs" on a 16:9 HDTV is something like:
- no top/bottom borders
- no scanline artefacts
- no scaling artefacts
- as close to correct aspect ratio as possible
but i could be convinced otherwise. are there any horrible examples where the image looks really stretched?
At the moment, the most obvious example would be vertical games on 4:3 displays, which, by default, are still getting output at 1120 x 1200 (i.e. almost square)
So, my approach can definitely be adapted to match your priorities, but I think had them ordered a little differently, and I tried to accommodate more than just 16:9 displays, focusing also on getting best results for 5:4 and 4:3 displays;
(the displays I have at hand for testing are 5:4 and 4:3 - resolutions of 1280x1024 and 1600x1200 respectively)- No / minimal borders
- Keep close to original aspect ratio
- No scanline artefacts for vertical games (where they're most evident)
- Minimal scaling artefacts
I think it's pretty apparent that our differing perspectives on the priorities are what bring about the differences.
I've done a fair bit of testing with the output of my script on the screens I have available, and I've been pleased with the results. Using non-integer scaling on horizontal games doesn't appear to introduce any scaling or scanline artefacts that I could readily detect. The screen is well filled for horizontal games, and the display is nicely proportioned for the vertical games.At the end of the day, though, looking at numbers in config files will only get us so far..
If you can spare some time to test my script and give some feedback on your subjective impression of its output, that would be great. I'm open to suggestions for further changes (maybe we can make some selectable options to allow users to better fine-tune it to their particular needs?)
absolutely! i have to set up a retropie for a friend (i am waiting for stretch support so i can test that also) so will take that opportunity to try your configs. i suspect i will prefer them :)
-
sigh...I thought about replying to your comments about my comments but I know it's kinda like going down a rabbit hole creating constant doubt with comments, code or methods you understand little to no more than I do from reading your replies. It just seems you always have a retort to everything but sometimes not knowing is ok. I kind feel like you'd stand at the pearly gates and kick St. Peter right in the teeth...before you'd let somebody play you.
From the get go Andrew not only answers questions but backs them up with the math. I could never even get you to explain two lines of code let alone get you to confirm you coded the whole script yourself out of curiosity.
Collaboration requires communication but you would never explain any of your script which lead me to doubt the validity of it's authenticity. It's not just waiting for someone who knows more to come along and do the work. There's no way I could have done better then Andrew but I was willing to try and would have learned a good bit. In fact I offered to help Andrew right away in a prior post but as it turns out he's a one man show that needs no help.
I don't imagine that you would be accountable and own it but the side poke was really unnecessary. You discretely closed the other thread, ignoring the post & encouraged everyone back to this post. Then promptly started challenging and trashing every comment I was writing. For what?! To show folks how smart you are at the expense of others. It does no one any good or help them learn to make them afraid or second guess what they don't know.
I was sincerely hoping for a bygone as I enjoy being part of this community. I was here on good faith to learn a bit about the process of the configs. I know I asked a lot of questions but it's how I learn and absorb information. I like to understand to the last detail. Truly understanding all aspects is the only way to write code or scripts. In fact you can't write code that works unless you fully understand the challenge at hand.
Honestly now I don't really care about the configs at this point due to the endless conflict. While they show a slight enhancement zoomed in they don't offer much un-zoomed. DaveJ's vertical shader fixed most of the issue. The slight artifacts I can live with. Not to mention they are completely incompatible with HD overlays.
Anyway If you had something to say about what I wrote I would had rather you addressed it directly instead of acting out with backhand comments. There's just a point where someone has to be the bigger person and walk away. Not that I am the bigger person but I am ok with walking away.
@AndrewH - Yes I did confuse pixel dimensions vs PAR. I still hope the same idea holds true. Porting from old arcade monitors to modern displays is a fundamental challenge the requires several different techniques to overcome PAR/DAR discrepancies from one to the other.
Just out of curiosity are you the same Andrew with a page full of utilities JavaScript & CSS experiments? Who's #1 app is about aspect ratios? Github account. I was wondering how you were picking this & Github up so incredibly quick. If so it's nice to see someone of your caliber leading the project. Your work looks pretty incredible with many helpful utilities!
-
@riverstorm Hey, I read your above note and think you probably don't need to feel the way you do. I have been on the outside of this discussion injecting my own observations/comments here and there, but also learning from your more specific attempts to understand the details.
I think it is easy to read into responses that are written to be very direct and interpret them as offensive. It's one of the problems with text, as you cannot truly detect the tone. That said, as I read through Dank's notes, I find them to be short, meaning they are pointed and brief, not necessarily impolite. I expect the original intent of this thread was to provide technical guidance to scripting the construction of custom viewports to avoid shader artifacts and not as much of a training guide for understanding DAR, PAR, AR, scaling algorithms, github, and so on. When you started the other thread, I was hopeful it could serve as the place for friendly discourse about all of that. The fact is, these custom configs are connected in principle to a very long list of side topics worthy of discussion that would produce (and has produced) tidbits of detail that many folks will benefit from. Yet, much of it distracts from Dank's original intention for opening this thread, while Andrew's efforts to enhance the script do not.
I guess I am saying, don't feel bad about this. I'd like to discuss some of the side topics. For example, I have a few notes to share about bilinear interpolation that I think will bring the idea of scaling vs. smoothing to a conclusion.
-
@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
@AndrewH - Yes I did confuse pixel dimensions vs PAR. I still hope the same idea holds true. Porting from old arcade monitors to modern displays is a fundamental challenge the requires several different techniques to overcome PAR/DAR discrepancies from one to the other.
It's not completely straightforward - I think we can all agree on that. Even with the helpful fact that digital pixels are square, optimizing for a wide variety of aspect ratios and trying to get the best results for each takes a bit of work. And then there's the fact that there's not universal agreement on what 'best' even looks like. For some it will be accuracy, for others filling the screen, and for others... who knows.
Just out of curiosity are you the same Andrew with a page full of utilities JavaScript & CSS experiments? Who's #1 app is about aspect ratios? Github account. I was wondering how you were picking this & Github up so incredibly quick. If so it's nice to see someone of your caliber leading the project. Your work looks pretty incredible with many helpful utilities!
No - that would be just coincidence, and I'm most definitely not that guy. I've had to dust off my long-dormant Perl memories in order to get sufficiently to grips with Python to do what I did, and then had to learn how to interact with Github along the way. I'm Andrew-H2O on there, and my contributions to date are only towards this script.
-
@caver01 - very well said, and supremely diplomatically put too. I don't want to find fault anywhere, but I can understand (I think) the perspective of Dank, who probably felt that his script was long since done and dusted. A new problem arose (4:3 aspect ratio screens), and there's been a lot of discussion since - some was directed towards addressing it through script change, and some has been a quest for greater understanding. Personally I feel that it's all been useful, but as you note, some of it has been tangential to the original purpose or intent of the thread.
Anyway, given that there's an interest in further discussion on some of the 'side topics', but that this mightn't necessarily be the best arena for it, maybe your or @Riverstorm would consider starting a thread in the General Chat section?
I'd gladly participate, as I'd hope you both would too.
-
@andrewh said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
No - that would be just coincidence, and I'm most definitely not that guy. I've had to dust off my long-dormant Perl memories in order to get sufficiently to grips with Python to do what I did, and then had to learn how to interact with Github along the way. I'm Andrew-H2O on there, and my contributions to date are only towards this script.
Ah ok, there's another AndrewH that has a site full of utilities and his #1 app happens to be about aspect ratio's and of course that's the topic. It's a small world.
-
this isn't my first rodeo with riverstorm, though. this weird vendetta has been going on for quite some time. my meagre changes to mame2003 were met with a similar questioning of my ability as a programmer, my understanding, etc.
can we go back to talking about aspect ratios, now? :)
-
@dankcushions said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
Questioning of my ability as a programmer.
Correct.
And this:
https://retropie.org.uk/forum/topic/14257/correcting-scaling-artifacts-in-lr-mame2003
-
we are almost ready to release the new .zips with @AndrewH's improved algorithm!
a check has been added to make sure that the scanline shader is NOT used in situations where the screen does not have sufficient resolution for the game. i forget the official figure from @davej, but I believe it was 3 or 4 pixels per scanline for good results. you can see an extreme example of the problem when you use the shader in games like darius, which has a very wide, high resolution image. the scanlines just appear like a grey haze... not ideal!
so, **a question for 720p users! **
following this change, the following games will NOT have the crt-pi shader applied for your resolution:- nba jam
- mortal kombat (all)
- smash tv
- r-type
- donpachi
(this isn't the complete list, which is 100s, just some popular games)
can you check these out on your screen with the crt-pi shader on? do the scanlines look acceptable? if so, maybe we could reduce the threshold, or make it optional or something like that.
-
@dankcushions Will this update fix or reduce rainbow banding issues? I only get them on an old Samsung 720p tv when using any emulator with the crt pi shader. It might be an isolated issue with these old TVs being 1366x768 or whatever res it is when using the vga port, but the hdmi ports only output 720p.
-
@darksavior said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
@dankcushions Will this update fix or reduce rainbow banding issues? I only get them on an old Samsung 720p tv when using any emulator with the crt pi shader.
are you already use the script's configs?
-
@dankcushions Not in a while. It’s a problem I’ve had forever and given up on it. If the scripts have been updated recently, I’ll give them a try when I can. It might be a combo of the shader itself with the tv...
-
@darksavior said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):
@dankcushions Not in a while. It’s a problem I’ve had forever and given up on it. If the scripts have been updated recently, I’ll give them a try when I can.
eliminating the rainbow effect is exactly the script's function :) that part of things hasn't changed a great deal. i wonder which ones you see the effect?
following the next update it will not bother applying shaders to certain higher resolution games on lower resolution screens, but for the majority of games you will still get the shader on a 1366x768 display.
-
Hi folks,
I have a native 1600x1200 TFT. Although I read most of the posts about this resolution here, I don't really understand what I should do for the best results with this resolution or if the latest version is "4:3 ready" by now. Could someone please enlighten me in a few words? Thanks. -
@clyde You would have to generate the configs using the script yourself, since I have not created a set for that resolution in the initial post. However, I am probably going to re-generate all the configs soon using a different shader, and could do you a 1600x1200 pack then. this probably won't be soon, though!
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.