(The flickering is more obvious when the control centre is opened, I managed to take a video of it but it’s only partially clear in it. It’s been about 5 minutes so far and I think the effect has reduced. I’m also quite perceptive to flickers so others might not notice it.)
If you alternate every other image with a different color value, you upset that balance.
It will slowly rectify itself for most displays.
This is called inversion and there are interesting web pages on the topic:
* http://www.techmind.org/lcd/
I guess you probably need a higher ratio for this to work really well.
Not to be confused with the "slang" shader format that Khronos is looking at to replace GLSL.
The other important factor is the light filter. The NES Zapper has a filter designed to only be sensitive to high-frequency light sources like CRT screens.
Safari by default caps animations other than scrolling at 60fps (I think?).
But I find it hard to say that what it's supposed to look like. Motion blur is considered fine and correct in the "film look". Our eyes do crazy processing and can't really be emulated by a display technology without going to crazy lengths with high DPI, high dynamic range, high refresh rate (to emulate certain effects, not because we can properly see 90+ or so Hz) and probably eye tracking.
I think I like the slight (static) pixel blur of CRTs more than the motion-related behavior. The crazy DPI numbers of state of the art screens are seemingly not so much about showing detail than about hiding pixels. Calculating all of these pixels is, in a way, a waste of work. I'm talking about ~100 DPI, i.e. making a decent resolution look nicer, not about making low res crap look blurred instead of pixelated.
Also, there's some optimizations coming to make it look even better depending on how good or limited your display is.
I wonder if there's a way to ask Android Chrome to ask for 120Hz.
- Adjust your black levels and white levels so there's no clipping
- I noticed 6bit TN panels tend to have problems, try IPS or OLED
- Lower GAIN_VS_BLUR to 0.5 at 120Hz, or 0.25 at 240Hz, if discoloration is bothersome.
- There are some optimizations coming in January 2025 as band-aid workaround for display limitations (especially low-Hz TN LCDs), even 240Hz is sometimes too low.
OLED at 240Hz looks better than LCD at 360Hz with the CRT simulator for example, so if you're buying a monitor to have 75%-90% motion blur reduction in your 60fps retro content, you will want to have a high-Hz OLED, see the motion blur physics at TestUFO Variable-Persistence Black Frame Insertion demo (in TestUFO 2.1) to understand how higher Hz can reduce motion blur of low frame rates more than lower Hz; it's just the laws of physics caused by ergonomic flickerless sample-and-hold displays, and BYOA (Bring Your Own Algorithm) approaches. I can emulate plasma subfields on a 600Hz OLED, and I can emulate DLP subfields on a 1440Hz OLED; but CRT is the gold standard; still it needs a large native:simulated Hz ratio to look realistic. It's very adjustable.
What will be the use case of plasma and DLP subfields emulation?
What about 24fps movie contents, is there a future with fluidity and no visible stutter by chance?
- 120Hz = can reduce motion blur by up to 50%
- 240Hz = can reduce motion blur by up to 75%
- 480Hz = can reduce motion blur by up to 87.5%
There's a new article on Blur Busters that's showing 120Hz-vs-480Hz OLED is more human visible than 60Hz-vs-120Hz, and easier to see than 720p-vs-1080p, and also why pixel response (GtG) needs to be 0 instead of 1ms, since that's like a camera shutter slowly opening & closing, but MPRT is equivalent to the shutter fullopen time. The science & physics is fascinating, including links to TestUFO animations that teaches about display motion blur and framerate physics.
Motion blur of flicker = pulsewidth
Motion blur of flickerless = frametime
So you need tons of framerate or short pulsewidth BFI/CRT/etc.
Can we please design software to be frame-drop-free? Ie. if it drops a frame, even once, send a bug report to the developer to fix it, and if he cannot, refund me for the hardware?
My analogue TV from 1956 does not drop frames, I can assure you.
This CRT simulator almost requires a dedicated GPU (AMD, NVIDIA, Radeon) and nothing running in the background, since it's a software-based simulation of a CRT tube. It is probable that an Intel integrated GPU from 2017 won't work, and neither will a cheap $200 Android phone do it smoothly.
It is doing almost 100 math computations per subpixel per refresh cycle, in a multi-gigaflop supercomputer called a GPU, so if you're running at 2560x1440x120x3, that's still blows past a lot of dedicated GPU abilities, as it's needing to do it on every native Hz, regardless of the low simulated Hz.
Make sure you don't have any software running in background (not even browser tabs, no system tray apps, exit your RGB animation apps), and run in Performance Mode (not Balanced Mode or Low Battery Mode).
It's frame drop-free on my Razer laptop in a clean Windows install, but it starts stuttering with an old Windows install. Not much I can do about operating system preventing realtime stuff.
If you don't understand why comparing a modern graphics pipeline, sitting ontop a general purpose CPU running a time sharing kernel, might be different enough to break the comparison to an old TV, I don't know how to help you...
I wanted to see something and clicked on the 120Hz version not knowing what my laptop display actually is and while I am not photosensitive this was quite uncomfortable. Thinking I don't understand what that is supposed to be I clicked on the 480Hz to see if that is better/different and that was even worse. As a hail mary I clicked on the 240Hz and well that really made sense and was actually comfortable to look at.
So if you are like me and didn't really read through the text, this will only work for you if you select the Hz that matches your display ( which kinda is the whole point of why they are doing that ). If it looks bad you clicked the wrong link
Retroarch now has this CRT simulator and it will automatically keep it at 60Hz by its default settings; so it's more foolproof in Retroarch than in Shadertoy.
However, the CRT simulator actually is variable-MPRT; it does compress the light emissions as quickly as possible as early as possible. Dim greys, for example are brightened and pushed in an earlier refresh cycle of the series that simulates a CRT refresh cycle.
So dimmer pixels get lower MPRT and brighter pixels get higher MPRT. Any unemitted brightness gets cascaded to subsequent refresh cycle until fully emitted to meet Talbot Plateau Theorem.
What makes it so complicated?
You need to keep the GPU free to work on the game; doing CRT simulation at 60fps at 480Hz requires brand 8 new frames per videogame frame, and it's doing a bunch of math operations per subpixel per refresh cycle. If you run it at full resolution 2560x1440x480x3, that's a lot of processing.
Especially since it also uses a variable-MPRT algorithm that cascades brightest pixels to subsequent refresh cycles;
That's why it's coming to RetroArch and best to process the low-resolution framebuffers first, before scaling and sending through CRT filters/simulated curvatures/etc.
Most retro games are just 320x240.
I recommend 240Hz OLED in arcade cabinets to emulate 60Hz CRT, do not skimp on Hz. More Hz is better for CRT simulators, due to a very important temporal principle, you need a large native:simulated Hz ratio.
> A: You need a bright display, try a 240Hz+ OLED. Also some local dimming LCDs have a backlight lag that sometimes interferes with quality.
Come on now. If you can simulate a CRT then surely you can make it look nice on a conventional monitor?
120Hz = up to 50% motion blur reduction for 60fps
240Hz = up to 75% motion blur reduction for 60fps
480Hz = up to 87.5% motion blur reduction for 60fps
CRT simulation is bottlenecked by limited genuine native non-faked Hz, which is why accurate CRT simulation is so difficult.
No they didn't.
> a photosensitive person may have damaged themselves
What person that might be seriously affected is going to look at the image at the top of the article and decide they want to try the full speed demo without extreme care? Plus there's a warning on the links.
Edit: I misunderstood and was running the 240 Hz version at 120 Hz. The 120 Hz version doesn't flicker noticeably. It does seem to reduce motion blur for 60 Hz content with a brightness penalty. It doesn't immediately make me feel like I'm looking at a CRT. Maybe it would if I had a 480 Hz monitor. There is a slight rolling banding artifact on my phone, maybe an artifact introduced by the display controller as described in the article.
- Throw as much native:emulated Hz ratio as you can.
- 120Hz = up to 50% blur reduction
- 240Hz = up to 75% blur reduction
- 480Hz = up to 87.5% blur reduction
- Calibrate your black levels and white levels (e.g. via TestUFO PLUGE test and White Level tests), since you need all of the levels for the simulated phosphor fades.
- Use SDR mode, not HDR, the math in the shader is designed to the Adobe sRGB curve. I wish I had more direct access to the complex HDR curves and ABL to auto-compensate for Talbot Plateau Theorem.
- Use odd number native:emulated Hz ratio on LCD to make it immune to image retention + slightly better behaviors with LCD 6-bit FRC
- Adjust Gain-vs-Blur and gamma, if there's problems. Using low Gain-vs-Blur will reduce color ghosting. Use 0.5 for 120Hz, and if you're getting too many artifacts, try testing numbers as low as 0.25 for 240Hz to see if color ghosting problems disappear. (A fix will be coming)
- Artifacts reduce dramatically at 480Hz versus 240Hz vs 120Hz, more Hz really helps CRT simulation. More Hz the merrier, for BYOA (Bring Your Own Algorithm approaches)
There will be an improved version of my shader on Github, involving:
- Global refresh mode (like a phosphorescent BFI)
- Color balancing modes
- Black level lifter (to fix any thin dark bands caused by violations to Talbot-Plateau Theorem due to certain displays' crappy handling of below-2% greyscales, etc)
Keep an eye out for it in January 2025, just star the Github repo or wait for Retroarch (etc) to implement the improved version of my shader (after I'm finished deadline work for a client at CES 2025)
240Hz demo in 144Hz mode looks flickery but much more realistic.
https://en.m.wikipedia.org/wiki/Interlaced_video
(Half vertical resolution, offset a bit every other frame)
If you have photosensitive migraine or epilepsy, stay the hell away from those demos.
