New CRT shader from Guest + CRT Guest Advanced updates

Maybe not but I think it is realistic. I’m pretty sure the lighting conditions would have to be right to see the physical mask, and that would lower contrast.

e.g. the black level in the three shots above looks pretty high.

3 Likes

Seeing that we’re already close to achieving that look using the glow/magic glow effect. Maybe it might not be so difficult to implement the full effect in future shader revisions?

I think stuff like this is important to assist in things like the “natural” anti-aliasing and superior blending of pixels and edges that are characteristic of CRTs without resorting to simple blurs to ease the high contrast transitions, which usually tend to soften the image or contributes to a lack of focus.

What it appears like to me is that it could be functioning as a type of physical dithering pattern.

I’ve noticed that the same image with darker scanlines can look sharper but also less pixelated than the same image without scanlines or with lighter scanlines.

It’s possible that these vertical lines can have a similar effect on the image. Maybe that’s part of the “magic” that Magic Glow adds to the image as a side effect?

I’m not so concerned about Black Levels because as @Nesguy always said CRTs didn’t have perfect black levels although they were close enough to perfect.

I think the effect fails using Magic Glow because the luminance tapers from a high level to a low level, while what we would need for this effect would be an extremely low but static luminance level across the board. Only where the phosphors are lit is where the luminance would be higher than this level.

So in essence I think we can achieve this by simply having some “background” luminance applied to the Mask even when the phosphors are inactive. So instead of the Mask/Phosphors going all the way down to 0 (Off, black), Maybe they should go down to 2 or 1 or 0.2?

We could probably call it Magic Black Level or Mask Black Level? I’m sure @guest.r could come up with a better name if he so chooses to implement this.

1 Like

I’m testing it atm, should look like this:

11 Likes

Oh Wow @guest.r! This is brilliant! I think @HyperspaceMadness might also appreciate this very much since it’s something that he had pointed out that he noticed for a while. Thanks a mil for taking things even closer to the real thing!

4 Likes

Hi, I am kinda new to retroarch. Not a newb to emulation tho. I am wondering, where do I place the update? I have Sonkun’s shaders installed and working properly but uncertain about where I need to place the presets. Sorry for such a simple question

1 Like

I know it’s early days still but instead of this:

I’m seeing this:

20230713_123934

20230713_124020

So there’s a black halo?(shadow?) around the glowing phosphors. I think this might negate some of the blending properties of the effect even though you’ll still get to see the barely visible mask.

For the proper effect the phosphor must glow and blend on top of the energized mask with no black separation between the transition by default unless it is artificially added in case one would want more sharpness.

I think if you nail this, you might even be able to get away with less blur on the emulated phosphors themselves while still having smoother edges than what might have been possible before so the net effect might be a sharper, clearer image due to lower phosphor blur but smoother edges due to edges gradually fading into the inactive phosphor colour instead of a sharp black drop-off.

1 Like

One question: should this new effect be uniform all around the screen, or should it be stronger near actually illuminated phosphors? I would think it’d be the latter, and judging from pictures from the CRT thread in this forum, it would seem to bear out, but I can’t really say without an actual CRT in front of me, and even then I suspect other factors may come into play depending on the CRT and how it’s calibrated. And how would it play with the existing Glow and Halation parameters?

1 Like

I think this is your answer right here:

It’s the unenergized phosphors that can be “passively” visible so there’s no energy being applied to those to create any excitement of the phosphors and thus difference in light output. So of course it’s going to be uniform.

This is what Magic Glow already does brilliantly.

1 Like

Into the crt folder in the shaders_slang main folder. You don’t copy the base folder in the zip, but the folder’s content and you are good to go.

Yeah, i noticed it also, i guess this looks better:

6 Likes

Place the sonkun folder right into the shaders_slang folder and you should be good to go. Welcome to the forum by the way. If you have any other questions you can send to my thread as well right here:

1 Like

We both replied to him at the same time lol.

Also @guest.r while I’m at and since it seems you’re working on another update I have to bring this up again. If it’s possible can you try to make it to where I can place the new upgraded grade shader into my presets where I usually always have it placed? I know you said that the after glow pass wouldn’t affect anything and that I could just place grade above it, I tried that and it indeed works that way but I really don’t want to see two different types of color managing shaders in my presets.

I think it’s a issue with the LUT or something when I try to replace the “pre-shaders-afterglow” pass with grade, not exactly sure. If it’s not possible I’ll just leave this topic alone going forward.

2 Likes

New Release Version (2023-07-13-r1):

Notable changes:

  • Base (black) Mask strength feature added

Download link:

https://mega.nz/file/p1p2yS7Z#4caaGaPofPLjyJhjuFslEAE7C4oqhONTqz6nYQ-VOzg

11 Likes

I think i’ll need some extra time to update the new grade version like the older one was adapted. I guess it’s best to put it on my schedule.

1 Like

Definitely, looks better. Great job!

This one and the next image appear to have a very slight black separation and possibly a very slight black outline between the inactive mask and the boundary of the phosphor glow but it could just be me.

20230713_140412

20230713_140517

It’s not visible at all to me in these red transitions though.

20230713_140711

This shows the combination of Magic Glow and the new Base (Black) Mask Strength feature quite well.

20230713_140929

The area to the left of the green character (in the original image) seems to display some afterglow.

Thanks a lot @guest.r! I’m looking forward to tweaking and playing around with this new setting!

Before this, one of the ways to get this type of effect albeit improperly was to increase the gamma so that areas which would normally be dark now show visible mask the downside of this would have been washing out the mask on the brighter end. Now we can have nicer edge transitions and fades/blends to near black without suffering this penalty.

I want to see the effect this has on previously very sharp, harsh presets.

Thanks again for your hard work and dedication to the community!

3 Likes

No problem at all. I’m just glad you’ll consider adding it in that way at a certain point. I wasn’t planning to do another update until I get that new grade in but in the mean time I’ll see what this new update is about that you just posted. Thank you for always making this shader better.

Hmm, there seems to be an issue with how this new feature interacts with Magic Glow around the edges of pixels. To best illustrate the problem, here’s the Base Mask strength parameter set to maximum, with Magic Glow enabled and set to its default value of 0.08:

Here’s the same, but using regular Glow:

2 Likes

Maybe it’s the same thing I was noticing just amplified. It could be one cancelling the other. Remember, the two are supposed to either mix (additively) or be one in front (or on top of the other). It is quite possible that depending on the math and implementation that one is cancelling the other.

Remember both algorithms are trying to determine the final output colour of basically the same pixels. Maybe some tweaks to the way both are blended might need to take place?

Regular Glow doesn’t show the same issue but regular Glow doesn’t use the emulated phosphors exclusively to generate its effect.

It just lights extra pixels even in between the mask and regardless of the phosphor colours instead of exclusively allowing the RGB mix of the phosphor colours to determine the colour.

One possible workaround in the meantime could be to not “abuse” the setting until this cancellation is visible. Remember this is supposed to be something that’s very subtle and hardly ever visible. Perhaps testing at much lower levels of Base (Black) Mask strength might reveal a much more acceptable level of cancellation or maybe none that is visible at all?

If that be the case then there’s no need for change in the shader. So maybe try balancing Magic Glow and Base (Black) Mask a bit until you can barely see the unexcited Mask and there’s no black halo between the transitions and perhaps you might have your sweetspot right there.

Testing it further, it’s weirder than I thought. The black “halo” doesn’t change size or shape no matter what you change in the Glow parameters (it only seems to respond to Scanline and Sharpness changes, which change the shape of pixels, so that’s to be expected). Also, even if you set Glow Strength to 0 (which should disable it altogether), it still appears so long as Magic Glow is enabled, and immediately goes away when you disable it (i.e. enable regular Glow). Even stranger still is that the Magic Glow Mask Strength parameter appears tied to the Base Mask parameter, so if you lower it all the way down, you can no longer see the phosphors in the Base Mask, although raising the Base Mask parameter still brightens up the black areas of the screen. Not sure if that’s intended.

As for striking a balance, as it is, you basically have to have Base Mask set to 0.02 or 0.03 at most to not really notice the “halo”.

Anyway, here’s a shot using negative Glow values (also testing out the NES color decode shader, so that’s why the colors look different). I think it looks alright:

2 Likes

Interesting that you got it to work because I was just about to type that I concur with your findings. It’s really weird in my testing so far if you leave everything else at defaults and just enable Magic Glow and start to turn Base (Black) Mask strength up.

So I guess you need to be using negative glow values only for this to work then?

Does the NES Colour Palette have anything to do with it?

Okay, just realized that the black halo is exactly the area that gets affected by glow when you switch from Magic Glow to Ordinary Glow.

Changing (Magic) Glow Strength from +0.08 to -0.08 didn’t help.

I’m using the Sony CXA2025AS Palette in Mesen.

When I switch the Palette to Raw it seems to go away but I’ve never used the NES color decoder shader so I guess I have to prepend that for everything to work properly at least in Mesen.

So right now my colours are completely off. Maybe the halo only affects Black. There’s currently no black on my screen due to the Raw Palette being enabled without the decoder.

Update:

When I presented the nes-color-decoder.slang the black halo came back. Again when I switch Magic Glow to Ordinary Glow the glow fills almost the identical area as the black halo.

What I can say is that using the Ordinary Glow with negative values seems to be providing the effect that I was expecting. With positive values not so much due to the coloured pixels infiltrating the mask.

Definitely looking good with negative values. Even with the default low positive values the horizontal spread doesn’t seem enough to negatively impact the mask that much and you definitely don’t want to go overboard on the negative values either or you’ll end up with a “heatsink”.

So Magic Glow + Base (Black) Mask Strength seems to be a no go but it probably isn’t needed because Ordinary Glow works fine with it, especially negative values.

So probably nothing to fix. In any case this new parameter can actually replace the Magic Glow in a way that’s more realistic in my opinion so the two don’t necessarily need to be active at the same time.

Thanks again @guest.r!

No, the color decode shader has nothing to do with it. Negative Glow Strength values only do anything different if you use regular Glow. From what I can tell, Magic Glow does the same thing with positive and negative values. In other words, there’s three types of Glow:

  1. Regular Glow (positive values)
  2. Regular Glow (negative values)
  3. Magic Glow (positive and negative values do the same thing)

Base Mask works just fine with the first two. It’s Magic Glow that has the black “halo” problem regardless of what value you use, whether it’s positive, negative or even 0.

1 Like