Yet, another CRT Shader

RetroArch Additions Shaders
#81

yeah I just tried it with the snes port of the original SF2, same thing (doesn’t matter which snes core). since the SAR is 8:7 on the snes I chose 16:10 as the DAR to better demonstrate the effect: https://imgur.com/a/4EiOb

I guess the behavior is expected since the AR stretching is done after the shader rendering (I think). unless you choose a whole multiple of the SAR the pixel repetition becomes irregular (with nearest filter). well the same thing you explained with the sharpness parameter in your shader.

#82

Sp00kyFox, I don’t get these artifacts here, even on 16:10 or 4:3. Are you sure you’re using the version in common-shaders? The last version there fixed a lot of bugs.

#83

[quote=“Hyllian”]

But, is this using Integer Scale enabled? I think if a not multiple of native resolution is used, the scanlines can’t be equally spaced with nearest filter.[/quote] Ah you’re right, that’s ok with integer scale ON.

#84

just updated retroarch and my copy of the shader repo. yeah, still the same effect. what I found out though is that it isn’t so noticeable with higher scale factors but nontheless still there. the thing with integer scaling is that it’s kinda bypassed. it only fixates the vertical resolution but not the horizontal one otherwise custom aspect ratios wouldn’t be possible with this option activated.

edit: maybe video driver related? d3d isn’t working for me in newer retroarch versions so I can’t test it.

#85

Any ideas why im unable to get this shader to work as per my post at the top of this page?

#86

just updated retroarch and my copy of the shader repo. yeah, still the same effect. what I found out though is that it isn’t so noticeable with higher scale factors but nontheless still there. the thing with integer scaling is that it’s kinda bypassed. it only fixates the vertical resolution but not the horizontal one otherwise custom aspect ratios wouldn’t be possible with this option activated.

edit: maybe video driver related? d3d isn’t working for me in newer retroarch versions so I can’t test it.[/quote]

I think so. I can’t reproduce this glitch, so I cant fix it for now.

#87

no problem. like I said in the beginning, it just works fine with linear scaling as the default filter.

#88

ok got it. I think I know why you couldn’t reproduce the moire effect. you probably deactivated the phosphor effect, can that be? cuz the phosphor effect introduces brightness changes in regular steps in horizontal direction. if the horizontal strechting for the aspect ratio is done with nearest neighbor the pixel repitition / deletion falls irregularly in and between the phosphor cells and thereby creating the moire effect. by deactivating the phophor option this irregularity is technically still there, but becomes hard to notice.

#89

No, I haven’t deactivated the phosphor effect. You can see by the picture I posted earlier at 4:3 and without those glitches.

BTW, I’m finishing V11. Can you test it? I fixed a small bug in horizontal pixel transitions which were only perceptible without phosphor effect.

By default, it isn’t using the phosphor mask now, because proper Naked CRT is beautiful! :stuck_out_tongue:

Here it is: http://pastebin.com/QBUBGv92

#90

Works nicely here. Lots of good options to play with! :smiley:

#91

well I don’t know why it’s not happening on your side. I tested your new version and like I already suspected it has the same behavior.

ok, plz test this for me. activate integer scale, put retroarch in a window with x- and y-scale of 1.0, set aspect ratio to “core provided”, deactivate any shader and make a screenshot of the character select screen of SSF2 (snes) with default filter “nearest” and one with “linear”. compare it to my screenshots:

https://imgur.com/a/DJgwd (3x scaled with nearest neighbor to better examine)

#92

Here they are:

http://imgur.com/a/moYzp

The same as yours I think.

#93

yeah…, I don’t get it. if it behaves the same way in this case why our results doesn’t match with your crt-shader??? let us put this moire issue behind us, I don’t really consider it as a bug anyway. it’s fixed on my system with linear filtering and that’s it ^^

#94

BTW, found an amazing combination in 4chan that droped my jaw:

http://pastebin.com/SR35mHy5

It looks incredible:

#95

I use the same combination since a few months but my .cgp file isn’t that complex. Why 3 passes instead of 2 ? Can anyone explain me what wrap_mode0 = “clamp_to_border” and float_framebuffer0 = “false” means ? i’m not a coder but i’d like to understand

my cgp contains only few parameters ans seems to work well …

filter_linear0 = false
scale_type0 = source
scale_x0 = 2.0
scale_y0 = 1.0

filter_linear1 = false
scale_type1 = viewport
#96

Well, the more you know, the more you need to learn…

I didn’t know about these kind of combinations, because I had a false common sense that using xbr in only one dimension would create a lot of artifacts. So, I would never try that thing on my own.

I’ll try your cgp later to see if it is equivalent to the other one.

float_framebuffer means the format each color channel is stored. Using it false, each color channel (argb) is stored as 8 bit information. Using floatframebuffer=true means it will use 32bit to represent each channel in float format. I think there arent any shader which uses more than 8 bit to represent a color channel, so it’s better not using it for now, or else you’ll get a speed hit. And I think only RA for PC can enable it.

EDIT: just tested the flamex cgp and it works like the other one. Simpler and faster!

I’m using this cgp and it looks very good:


shaders = "2"
shader0 = "../xbr-hybrid/2xbr-hybrid-v4.cg"
wrap_mode0 = "clamp_to_border"
float_framebuffer0 = "false"
scale_type_x0 = "source"
scale_x0 = "2.000000"
scale_type_y0 = "source"
scale_y0 = "1.000000"
shader1 = "../crt/crt-hyllian.cg"
wrap_mode1 = "clamp_to_border"
float_framebuffer1 = "false"
#97

This shader works on low-end systems too. I tested it with my toaster and I can get fullspeed in games. I’m pointing this out because if you later make changes that increase the power needed to run it, I’d recommend keeping an older version around for low end systems. Specs:

Intel Mobile Core 2 Duo T6400 @ 2.00GHz 512MB GeForce 9300M GS (Acer Incorporated [ALI])

Questions:

  1. What settings would you recommend for running it at non-integer scale?
  2. The lines seem much darker when used on GBA games. Is there anything to fix that?
#98

Probably it won’t change too much from this version. I think I reached a good picture quality with many customizable parameters. I don’t intend to add other accessory things like curvature or bloom, for example. It’ll be a plain flat shader.

  1. As long as you keep vertical resolution as a multiple integer of native resolution, you can stretch horizontally to your taste.
  2. You can adjust the scanlines by changing the param SCANLINES_STRENGTH.
#99

Wait, I’m an idiot. I was using the dev builds, which typically have out of date shaders. The version I used was:

crt-hyllian-v2.cg

Which gets fullspeed. Using the most up to date version, I can’t get fullspeed on the craptop.

It might make sense to make another shader based on earlier versions and aim it for low end systems or mobile. I don’t think any CRT shaders are fast enough to run on mobile.

#100

Try this version and see if it runs fullspeed: http://pastebin.com/tVfJW5m9