the bar traveling up the screen is part of the LCD persistence prevention. You can turn it off in the parameters.
2 Likes
I did try that and the bar just seemed to stay in one place
1 Like
thatās right. It might need some other parameter to try and push it offscreen similar to the RTSS tear-line thing.
There might also be something up with individual displays. If itās a full-black bar, it may be rated to a sort of clipping thing that some monitors are apparently doing.
2 Likes
Ah, good idea, maybe Iāll try that, maybe being adjusted towards the bottom would be much less visible.
Yeah, thankfully Iām not getting a black bar, just a band that is dimmer than the rest
1 Like
No way to get rid of the horizontal stripe/bar. Thereās nothing in the parameters for this. Itās just the shader not being compatible with all monitors.
1 Like
try adding a parameter to the line:
float crtRasterPos = mod(effectiveFrame, EFFECTIVE_FRAMES_PER_HZ) / EFFECTIVE_FRAMES_PER_HZ;
I think just a float added to the end of it may do the trick. I donāt have that artifact here, so I canāt really test, unfortunately.
More motion blur reduction with less flicker than BFI. Phosphor decay and rolling is much gentler than squarewave BFI. It looks better than BFI, as long as you can calibrate the artifacts out.
- 120Hz ā You can get up to 50% motion blur reduction for 60fps
- 240Hz ā You can get up to 75% motion blur reduction for 60fps
- 480Hz ā You can get up to 87.5% motion blur reduction for 60fps
You can see 120-vs-480Hz is more human visible than 60-vs-120Hz, so do not hold back your Hz upgrade.
Some tips:
-
The band moves vertically because of the LCD Saver system (prevents image retention) but the band should not be blatantly visible, if you properly calibrate (ideally).
-
Make sure youāve calibrated your black levels and white levels. You can use www.testufo.com/blacks and www.testufo.com/whites ā
-
If you have any black clipping or white clipping, you may get some bands. Try slightly lifting your blacks and/or dropping your whites a little bit, and see how that goes. You could try a picture adjustment shader before the CRT simulator shader too.
-
Also, ABL/APL behaviors will be a big problem with some displays because the display can dynamically readjust itself on the fly mid-scanout, ruining the Talbot Plateau mathematics, and creating banding.
-
Try both SDR mode and HDR mode, sometimes it behaves much better in SDR mode. Try much lower GAIN_VS_BLUR values (āBrightness vs Blurā in RetroArch) and see what happens too.
-
Picture adjustment shaders MUST come before CRT emulation filter. No picture adjustments (contrast/saturation/gamma) can occur afterwards, since it could violate Talbot Plateau Law and create banding. When you design shader sequences, sequence things the same way as a real picture tube (picture processing circuit -> electron gun with electron beam -> hits phosphor).
-
Temporarily turn off your CRT filter, and see what happens. Some CRT filters arenāt very Talbot Plateau compatible. If you choose an end-stage filter, make sure itās not adjusting the picture in post-process while filtering (will distort the Talbot Plateau law because most postprocess color adjustments are in gammaspace, rather than linearspace).
Try various different CRT filters. Certain CRT filters have incompatible maths, some of the CRT phosphor filters seem to not be properly Talbot Plateau preserving (energy level preserving). This is the stupendous challenge of overlapped gradient rolling scan, where I must keep average photoncount consistent despite the shingle-overlapped-phosphor-fade subframes, which requires Talbot Plateau Law perfect mathematics ā and postfilters sometimes distort this. Not all of them do, but some of them do ā experiment with different filters, and moving the picture-adjustment filters to pre-CRT-beam scanning.
1 Like
Actually I made the band disappear with some of the above tricks.
It varies by display but sometimes I got the band to be 90-99% fainter.
Try (1) raising your blacks to a dim grey, (2) lowering your whites, (3) trying both HDR and SDR mode, (4) lowering GAIN_VS_GAMMA, (5) donāt do any picture adjustment filters AFTER the beam sim, only BEFORE the beam sim, (6) Turn off all NVIDIA Control Panel adjustments and reset them to defaults, (7) disable any Windows .icc calibration profiles and go to display native colorspace (and do picture adjustment in RetroArch BEFORE the beam filter), and (8) try changing CRT filter shaders (some creates more banding than others) / disabling CRT filters. Some CRT filter shaders violate Talbot Plateau Law with the beam.
Technical/Scientific Rationale;
-
(1) and (2) Is because on some displays RGB(0,0,0) is the same color as RGB(10,10,10). So you have to compress your gamut (e.g. HDTV 16-235 or subtle things like 2-254) to bypass the banding region;
-
(3) Most displays do this beam simulator better in SDR mode but sometimes it looks better in HDR mode;
-
(4) Lowering this number will cause less complicated Talbot Plateau stacking (less blending), especially when done in conjuction with (1)+(2);
-
(5) Picture adjustments after the beam sim will tend to distort the Talbot Plateau perfection and start banding;
-
(6) Same reason as item 5
-
(7) Same reason as item 5
-
(8) Some filters distort the Talbot Plateau behavior at the dark tip of rolling scanout where it overlaps the bright tip of the previous refresh cycle. You may be able to fix some of this by doing the tweak in item (1)+(2) to lift blacks and lower whites. But not all filters fix themselves this way. So temporarily disabling filter may also produce a sudden disappearance of banding on some displays, as the banding was traced to certain CRT filters.
Also, try blurry-pixel filters too, and see if that produces better results than sharp-pixel filters too.
If you still cannot get your banding to disappear despite the above (even with very grey blacks or dimmed whites), it could be also due to a 6-bit behavior in a TN panel. They tend to have difficulty with the subtle shades at the phosphorfade tips.
1 Like
If your native:simulated ratio is even on an LCD, do not do this. It intentionally ROLLS to prevent image retention on an LCD. This is because my CRT shader is capable of non-integer native:emulated Hz ratios, and I piggyback on this trick to slew the emulated Hz relative to output Hz.
For 60.000fps at 120.000Hz, itās actually very explicitly intentionally emulating a ~59.985Hz CRT, to prevent image retention from static electricity buildup from voltage-polarity inversion algorithm in LCDs. See LCD Image Retention from BFI. The CRT shader automatically avoids this, as per math algorithm in shader:
// LCD SAVER SYSTEM
// - Prevents image retention from BFI interfering with LCD voltage polarity inversion algorithm
// - When LCD_ANTI_RETENTION is enabled:
// - Automatically prevents FRAMES_PER_HZ from remaining an even integer by conditionally adding a slew float.
// - FRAMES_PER_HZ 2 becomes 2.001, 4 becomes 4.001, and 6 becomes 6.001, etc.
// - Scientific Reason: https://forums.blurbusters.com/viewtopic.php?t=7539 BFI interaction with LCD voltage polarity inversion
// - Known Side effect: You've decoupled the CRT simulators' own VSYNC from the real displays' VSYNC. But magically, there's no tearing artifacts :-)
// - Not needed for OLEDs, safe to turn off, but should be ON by default to be foolproof.
#define LCD_ANTI_RETENTION true
#define LCD_INVERSION_COMPENSATION_SLEW 0.001
To avoid this, get an OLED (and disable this feature, if already exposed via Retroarch menu), or use an odd-number native:emulated Hz ratio. This will automatically turn off the LCD saver mode, as odd ratios are immune.
The slow analog-like slew is usually better than a sudden flicker every 10 seconds (crude framedrop method to switch voltage polarities). If you see bands, then calibrate them out if possible. Then the roll is largely invisible to human eyes. Thatās why hunterek does not see it, the bands are invisible, but itās still rolling (invisibly).
1 Like
Thatās what i was told in the github thread after i posted my monitor model.
I tried most of the solutions already so this is simply my monitor.
Hey guysā¦ Iām finally getting around to checking this feature out. I enabled āshader sub-framesā to get the rolling scanline optionā¦ my question isā¦ should I be enabling this universally, or only for certain cores/setups?
Youāre not actually using the rolling scan option. Enable the subframes and then use the crt-beam-simulator shader located in shaders_slang/subframe-bfi.
1 Like
Ah, okā¦ thanks. I was looking for the shader under the āblobā folder mentioned earlier, somewhere and couldnāt find it. So, once I enable the subframes, I should leave the rolling scanlines option that appears off, or turn it on in tandem with the shader? Thanks for the help.
leave the rolling scan option off. itās unrelated.
1 Like
Roger thatā¦ thank you.
So, question for HSM (or anyone who wants to answer)ā¦ to get this going with MegaBezel, do you just add in a #reference line at the top of the .slangp (for Guest ADV or whatever you are using) pointing to the crt-beam-simulator?
1 Like
Fixing Issues with CRT Simulator: Banding / Erratic Flicker
Update, I have created a HOWTO in my github issue tracker.
- Fixes for erratic flicker
- Fixes for banding
- Reduce chroma ghosting a bit
2 Likes
It didnāt work on your 6bit TN panel? Disable post-CRT-filter picture adjustments + disable drive picture adjustments + Turn off CRT filter or switch filters + recalibrate display Brightness/Contrast with test pattern linked from the above page. I updated and expanded the HOWTO with more tips.
1 Like
I did all these, the stripes are still there. I have to make the image completely dim to make them less noticeable and even then they are still there.
Lolā¦ āImproving motion blur reductionā¦ purchase new monitor if neededā. Nice tip.
So Iāll need to add this to the Mega Bezel chain and do a new release, which I should be able to do this this week or next. Itāll go right before the pre-crt stage in the shader chain.
3 Likes