Yes, Afterglow works by taking pixels which would otherwise be black and if they had color on previous frames this is blended in. If the pixel’s color was never black then it will never get any afterglow. It was something like this that I had run into, so I had to move the color correction affecting the black after the afterglow pass.
In the end I switched to the mame phosphor persistence method which doesn’t have this issue. It also only requires 2 texture samples rather than 5-6 samples.
With the I/Q shift, black is also tinted. Is there a way to keep black black?
Also, why is the range from -100 to 100 when even +10 or -10 seems like way too much? In what situation would you need this much range? Just curious.
@HyperspaceMadness Thanks a lot, I was pulling my hair out just wanting to wrap up already! I overlooked that line so I will think about what to do there.
@Nesguy, it’s adding values to each plane, when doing the inverse conversion it takes into account the added values. These formats are not really luma agnostic like White Point’s Yxy. I’m not really sure if this is CRTs behaviour, that code block was copied from Doriphor’s ntsc shader but I might have a look at it. I’m just really tired of this shader and want to jump into other things lol.
Updated afterglow removing the hard limit. Also if someone tested my mod before and wasn’t working test now as it had a wrong function type that has been corrected.
Eventually I will merge this into glass.
Been playing around some more with the grade shader, great stuff 
Reading the presets readme your suggestion is to use a SMPTE-C gamma of between 2.35 and 2.55 for NTSC-J. Should I just be using a value that “feels good”, or do you have a suggestion maybe on how to settle on a value in that range?
It’s quite interesting to see more depth in the parallax scrolling in the SNES games I tested when using grade with your suggested presets. (I guess colors in these parallax layers were originally chosen to create that sense of depth.)
######################################...PRESETS...#######################################
##########################################################################################
### ###
### PAL ###
### Phosphor: EBU (#3) (or an EBU T3213 based CRT phosphor gamut) ###
### WP: D65 (6504K) ###
### TRC: 2.8 SMPTE-C Gamma ###
### Saturation: -0.02 ###
### ###
### NTSC-U ###
### Phosphor: SMPTE-C (#1) (or a SMPTE-C based CRT phosphor gamut) ###
### WP: D65 (6504K) (in practice more like ~8000K) ###
### TRC: 2.22 SMPTE-C Gamma (in practice more like 2.35-2.55) ###
### ###
### NTSC-J (Default) ###
### Phosphor: NTSC-J (#2) (or a NTSC-J based CRT phosphor gamut) ###
### WP: D93 (9305K) (or keep D65 and set "I/U Shift = -0.04") ###
### TRC: 2.22 SMPTE-C Gamma (in practice more like 2.35-2.55) ###
### ###
### *Despite the standard of 2.22, a more faithful approximation to CRT... ###
### ...is to use a gamma (SMPTE-C type) with a value of 2.35-2.55. ###
### ###
### ###
##########################################################################################
##########################################################################################Basically “feels good” as each CRT was tuned differently, but if you want to be academic use 2.22. I personally like higher numbers as it depicts a more vintage look.
It is very interesting because yesterday when tuning the shader for different systems I really could see through developer intentions or employed CRT/gamma. I found out that later systems like PSX standardized these kind of things and as such for this system, Saturn and the like I ended up using 2.22 switching on sRGB and SMPTE-C gamma type back and forth, you have to keep in mind scanline darkening compensation. Same with temperature, going forward in time means lowering temperature to D75 and finally D65.
Updated glass.slang, small fixes I had with mask centering and a noise dithering pass for the reflection out to avoid banding AND add some sexy grain on dark backgrounds, it feels very CRT.
As I said yesterday I merged afterglow to glass with the clipping issue fixed. The shader is now in a very mature state so I invite you to check it out. I still need to rebase glsl with all the updates.
I’ll test out glass in a 3-4 hours. Looking forward to it!
Could you explain how the glass shader works and what settings do what in it? As some of it is confusing me.
Yeah, It’s very simple. I’d use Zoom convergence type for curved screens, and shift convergence for flat screens. Screen flicker and jitter should be very subtle and not everyone’s thing but play with it by raising the values.
I think still some setting renaming and repositioning should be done for clarity
g_csize "Corner size" - The usual corner size from crt-geom
g_bsize "Border smoothness" - The usual border smoothness from crt-geom
g_flicker "Screen Flicker" - Screen flicker factor, 0 to disable
g_shaker "Screen Shake" - Screen jitter/shake, 0 to disable
g_refltog "Reflection Toggle" - Disable all inner/outer reflections
g_reflgrain "Refl. Deband Grain" - Deband the outer reflection if you find banding/posterization
g_reflstr "Refl. Brightness" - Inner Reflection Brightness
g_fresnel "Refl. Fresnel" - Outer Reflection Brightness
g_reflblur "Refl. Blur" - Outer Reflection Blur
gz "Zoom" - Outer Reflection Convergence (adds to per channel)
gx "Shift-X" - Outer Reflection Shift X (adds to per channel)
gy "Shift-Y" - Outer Reflection Shift Y (adds to per channel)
gzrgb "Zoom RGB" - Outer Reflection Convergence per channel
goxyrgb "Shift-XY RGB" - Outer Reflection Shift per channel
I forgot also:
TO "Afterglow OFF/ON" - Enable phosphor afterglow
PH "Phosphor Index" - Use a phosphor index like in grade for afterglow luminance contribution (-1:P22 1:NTSC 2:NTSC-J 3:PAL)
PER "Persistence (more is less)" - Afterglow decay strength (the curve is a fixed function based on the luminance contribution)
ASAT "Afterglow saturation" - Afterglow saturationDoes the deconvergence only affect the outer reflection areas? I’m asking because of what you posted.
Also everything seems to be working fine, the flicker is nice and the jitter is interesting. I have another effect that’d I like to suggest, but I’ll have to find it next time on my PC. I feel like it’d go with what you’ve been doing.
With regards to the grade shader, when using your presets for PAL, NTSC-U and NTSC-J, would there be a benefit to getting a wide gamut monitor, i.e. would the CRT emulation be more accurate with your shader on wide gamut monitor, or is a well calibrated sRGB monitor good enough? (Bit confused also on the wide gamut settings you added, as it seems guest-venom already included those? Do both need to set to for example DCI to get correct results?)
Re the glass shader, where do I insert it in your guest-venom preset? I would like to have both grade and glass active to try it :). Maybe adding a preset that includes both would be useful to lower the barrier for people to try it out…
Replace the afterglow pass with glass.
I think I borked it when implementing afterglow. I forgot to pass through the deconvergence code to the afterglow texture sampling, so there’s an issue there now, but will fix ASAP. Yes please, share the effect to see if it fits into the scheme of the shader. One thing I really want to add (well aside the unfinished rolling shutter) is some horizontal interference warping. I know it’s been done before but haven’t looked into it. I guess it would basically be some sine horizontal noise that warps the texture coordinates.
@rafan A wide gamut monitor without a proper gamut mapping is not useful at all. That’s why all the color profile matrices (sRGB, DCI…) but that’s not enough, you really need your very own display transform matrix (or LUT). I assure you that your display deviates a lot to the specified gamut. For instance, retro games have a lot of out-of-gamut saturated colors, with the CRT emulation we bring them down a bit, but they are still out-of-gamut, yesterday I did a test on my DELL U2715H IPS monitor and the colorimeter and with grade NTSC-J emulation there was still some out of gamut values, the more pronounced was Sonic’s blue, it got toned down to a more azure blue, which makes sense. Here some screenshots.
I’m trying to follow…
As far as I understand you, a well calibrated sRGB color gamut on the PC monitor is better than having a non-calibrated wide gamut monitor (or limited wide gamut, e.g. the “90% DCI coverage” wide gamut monitors)?
Suppose both A and B below are a realistic possibility, is option A or B preferred for getting the best results with your shader?
A. sRGB monitor calibrated to 99%+ sRGB space
B. wide gamut monitor calibrated to 99%+ DCI space
Also I read on the DELL site on your monitor the following: Get exceptional colour accuracy and consistency straight out of the box, with each monitor factory tuned at 99% sRGB with a deltaE less than 3.
Why would there still be need to calibrate things yourself then?
Just trying to understand
Yes exactly that. With wide gamut monitors the error bias is even greater so the more need to calibrate, profile and gamut map, but as you said a well calibrated sRGB display is much better than non-calibrated whatever. For a sRGB to sRGB comparison you can see the differences on the Sonic screenshots, one has to think if it’s worth it or not (for me it is though), but for wide gamut the differences will be greater.
As for your example, given both are calibrated, B is the preferred option. The DELL marketing line is just that, marketing, I bought it for the capabilities (gamut, IPS) not for factory settings, I would guess serious precalibrated monitors would be the EIZO’s but I don’t know, don’t have that money. I’m thinking on changing this to a BFGD when they lower prices.
Could you elaborate on this? (As this may be what I was going to suggest, lol.) Is it similar to the horizontal waviness in newpixie-crt?
I think so. A shader I really liked was the pal-r57shell, but I haven’t borrowed any code from it yet lol. As with everything a little goes a long way, so a little of this and that even if it doesn’t make much sense, sum up and you get something else. Something I’m thinking about is s-video emulation, currently it passes the (de)modulation pass and creates some waviness, I might capture the waviness to distort the uv’s (or just fake it) but actually blur using the more accurate ntsc-signal-bandwidth shader.
BTW, I fixed the issue in glass, I’ll upload in a few minutes.
Ok, I think we are talking about the same effect, lol.
I totally agree that a bunch of little effects can build up to make way more than the sum of their parts.
I’ll test the updated glass, in a few.
I have a question about the deconvergence from glass, is it “redundant” (meaning I should pick one or the other of the deconvergence settings to tweak) if I already have deconvergence settings in my chain or is it doing deconvergence just for the simulated glass (so something different-ish)?
