New Release Version (2023-07-13-r1):
Notable changes:
- Base (black) Mask strength feature added
Download link:
https://mega.nz/file/p1p2yS7Z#4caaGaPofPLjyJhjuFslEAE7C4oqhONTqz6nYQ-VOzg
New Release Version (2023-07-13-r1):
Notable changes:
Download link:
https://mega.nz/file/p1p2yS7Z#4caaGaPofPLjyJhjuFslEAE7C4oqhONTqz6nYQ-VOzg
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.
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.
Itās not visible at all to me in these red transitions though.
This shows the combination of Magic Glow and the new Base (Black) Mask Strength feature quite well.
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!
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: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:
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:
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.
So it seems like allās well that ends well then. Looking forward to another one of @RetroGames4Kās CRT vs CRT Shader challenges because this was the one missing feature from shaders that always gave it away for me.
Oh sweet, Iāve been really wanting something like this!
Unfortunately it seems to not work correctly with slots, as theyāre being displayed over the phosphor pattern. Realistically, the slot mask sits behind the phosphor strips and is only visible when it blocks the electron beam, and not when the phosphors are lit externally. Hopefully itās easy enough to fix the order of the effects to address this.
Also suggesting naming the setting something like āUnlit Phosphor Levelā or āAmbient Phosphor Levelā instead.
ā
After further testing it seems the green strip isnāt visible enough at a reasonable low brightness (near black rather than gray) like it appears in the real CRT photos. Could you consider biasing green at lower levels, or maybe break out the setting for each phosphor color?
Havenāt tested Slot Masks yet but Iām really looking forward to. Hope it gets sorted out.
Update:
I didnāt observe this in my testing. Can you provide a screenshot to better illustrate? Slot Mask seems fine to me so far.
I think Iāve seen it before on the shaders, and works on slotmasks too, to achieve that effect I think is raising black level up if I remember, but Iām not sure if itās that option or another.
This is probably a different implementation probably by HyperSpaceMadness or Dogway. I remember when this was added to the Mega Bezel Reflection Shader.
I donāt think that was available in CRT-GUEST-ADVANCED/NTSC until now though.
What happens to the Mask in the Black areas of the screen when you raise the Black Level?
No, black level is different, it applies to the scan lines. That is not what this ambient phosphor effect does.
ā
Just increase Slot Mask Strength Dark Pixels
to 1 and it should be clearly seen in the background. This is at 0.12
, 0.06
, and 0.03
. This should not show the slots as theyāre situated behind the phosphor stripes.
I donāt doubt you but for these things I think we should pull out our reference material just to verify and properly communicate how itās supposed to look. Can you provide a clear image?
Iāll definitely go and see if I can dig one up.
What about you @RetroGames4K? Can you provide a clear gameplay photo of a dark area of the slot mask CRT screen showing how the unlit phosphors look!
This is an interesting shot:
It looks like Iām seeing the phosphors in front of the mask but due to the lighting and camera settings, it appears as though the slot mask wires are also visible.
Here are some more examples including different screen types:
For me it seems it lits up the phosphors of the black areas, if I donāt use it, it remains totally black.