Thank you, sir. I’m sorry for being disruptive.
My bad I had this déjà-vu feeling, it was just few posts above !
With mask intensity 0 the line indeed disappears.
Using pure-lcd this time :
Changing the .h file 99% fixes it, thanks ! 
What remains is actually a split from bottom-left to top-right with 0.5 or 1 pixel shift on each side that I don’t think I’d have noticed without the previous artifacting issue : here it is zoomed 500%
1 Like
Amazing work and I’m grateful to be witness to something special for CRT Emulation.
1 Like
Usually one gets rid of those kind of issues by multiplying the coordinates by 1.0001
Thanks for testing and the detailed report. I have an idea what the reason could be. These are probably arithmetic difference in how the mod, floor and other functions behave on different hardware.
@kokoko3k Yeah, there is already something like this in place, where I preciously encountered such artifacts, but not everywhere.
1 Like
@yyyeeeaaahhh I made some small changes to subpixel-helper.h. Could you manually download this file from GitHub and replace it with the one in the folder:
crt/shaders/crt-yah/common
Please tell me if anything changes. Also undo you changes the file crt-yah.fs.h.
1 Like
hmm nothing seems to have changed, after reverting crt-yah.fs.h, swapping both versions of color-subpixel-color.h give the same result with artifacting and seemingly no movement in the zoomed-in in picture
To be sure I used the right file I changed EPSILON to 7e-6 thinking it could trigger a noticeable shift, but then shader failed to compile. At least I know I was using the right file .
Yeah, increasing the EPSILON could work. The reason why it failed to compile is that EPSILON is also defined in other .h files with the same value, which is no problem. But when you redefine EPSILON with another value the compilation fails. If you want to test whether EPSILON is the problem, you either have to change it everywhere in crt-yah or you define a new EPSILON1 and use that in subpixel-helper.h.
Maybe another thing you could test for me is, whether the Mask Sub-Pixel Shape parameter has an influence. Try to set it to 0, while using the original get_subpixel_color() function call, because the other one doesn’t use the parameter.
I have raised a new PR with the attempt to fix the mask artifacts. It tries to make the floor() result more stable by adding EPSILON, which has been increased from 1e-6 to 1e-5 as well. The definition was also moved to a central constants.h file, to play with even larger values more easily.
There was another small update some days ago, that reworks the NTSC Jitter parameter.
My apologies, it seems to have been caused by setting Integer Scaling to X instead of Y.
1 Like
Thank you so much. This one is the best yet. I finally managed to set up the shader to almost look like TV. There were great shaders that I enjoyed a lot - koko-aio, cyberlab, royale - but they weren’t quite IT.
If there’s one thing that is kinda missing is flickering like in koko-aio. When brighter spots start shaking in comparison to darker spots.
1 Like
@PU786 You image is quite interesting.
When the Scanlines Strength is set to 0 (also by the Global setting) a sharp bi-linear filter is applied. In simple terms: it calculates the texel position in a bi-linear filtered image to the get color as if the image was not bi-linear filtered, but using nearest neighbor. If no integer scaling is used then there will be texel positions, which are exactly between two neighbor pixels, resulting in an average color of both, that you see as a thin gray line. And here comes the interesting part: This gay line should be between a white and a black pixel and not between two white pixel. It tells me that some calculation resulted in a value very close to the next integer, e.g. 2.999… but then was floored to 2.0.
I you like, you can have a look into the file crt/shaders/crt-yah/common/interpolation-helper.h and remove the + EPSILON from the two floor() functions to see if the issue will be gone. (or change the EPSILON in constants.h to 0)
@levonnn Thank! I’m glad you like it. Not sure if I can replicate the effect you mentioning, but I can give it a try. Btw. it would be great if you can share your settings.
I set it up for 1080p monitor (4K setting would’ve been different), it’s rather blurry, so it doesn’t give me scaling artifacts, plus I didn’t use curvature, but overall scanlines look great, with proper brightness and color. There’s some signal artifacting missing, but it’s not that big of a deal - other crt shaders don’t do them either.
#reference “shaders_slang/crt/crt-yah.slangp” GLOBAL_MASTER = “2.000000” SCREEN_RESOLUTION_SCALE = “1.000000” COLOR_TEMPERATUE = “0.000000” COLOR_OVERFLOW = “0.000000” BEAM_WIDTH_MIN = “1.000000” BEAM_WIDTH_MAX = “2.000000” BEAM_SHAPE = “1.000000” BEAM_FILTER = “0.550000” SCANLINES_OFFSET = “-0.000000” MASK_COLOR_BLEED = “1.000000” PHOSPHOR_DECAY = “0.950000” HALATION_INTENSITY = “0.000000” HALATION_DIFFUSION = “0.000000” NTSC_PROFILE = “0.700001”
2 Likes
I’ve seen your PR, but i think what @levonnn was referring to was the effect present in 15khz CRTs dealing with interlaced content, where bright scanlines used to “shake” over dark ones.
Unsure if it can be applied to your chain, but if you want, you can look for pixel_flickering(), here (please don’t mind the FLICKER_IN_MOTION thing), hope it helps!
Okay, then I misunderstood or rather did not think about it, because the effect was already there and is labeled Scanlines > Offset (-with .. +without Jitter).
Positive values only give an offset, which can be useful for games that were automatically down-scaled. Negative numbers make the scanlines move up and down in quick suggestion. It probably has not the exact same appearance as with you shader chain, though.
If it is modulated by the local vertical contrast, then yes.
No, mine it not that advanced. It just a simple coordinate shift, applied ever second frame at 60Hz. Still, looks quite convincing to me… 
1 Like
Sorry for the confusion. Your Scanlines > Offset (-with … +without Jitter) works strange. It’s shaking the whole screen, both bright and dark areas. While koko-aio’s version shakes only bright spots. Dark scanlines are steady. It’s called flicker there, but it’s indeed more scanlines jitter.
kokoko3k, thanks for the clarification.
Thanks for the feedback.
I raised a new PR where the jitter now also takes the brightness into account. It is still not as sophisticated as the koko-aio’s implementation.
1 Like