by bangonkeyboard on 12/25/24, 1:26 AM with 88 comments
by user_7832 on 12/25/24, 6:31 AM
(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.)
by modeless on 12/25/24, 6:21 AM
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.
by blensor on 12/25/24, 11:26 AM
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
by BlurBusters on 12/27/24, 7:08 AM
- 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)
by BearOso on 12/25/24, 6:33 PM
I guess you probably need a higher ratio for this to work really well.
by pavon on 12/25/24, 5:01 PM
by redox99 on 12/25/24, 7:25 AM
by ahartmetz on 12/25/24, 12:58 PM
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.
by vslira on 12/25/24, 4:09 PM
by yincrash on 12/25/24, 2:45 PM
I wonder if there's a way to ask Android Chrome to ask for 120Hz.
by nyanpasu64 on 12/25/24, 4:55 AM
by stuaxo on 12/25/24, 12:33 PM
by naoru on 12/25/24, 1:15 PM
240Hz demo in 144Hz mode looks flickery but much more realistic.
by Hakkin on 12/25/24, 5:15 PM
by stelonix on 12/25/24, 7:27 AM
by phafu on 12/25/24, 11:34 AM
by jtxt on 12/25/24, 5:09 PM
https://en.m.wikipedia.org/wiki/Interlaced_video
(Half vertical resolution, offset a bit every other frame)
by akoboldfrying on 12/25/24, 10:31 PM
What makes it so complicated?
by kristopolous on 12/25/24, 6:14 PM
by zanfr on 12/26/24, 4:40 PM
by isoprophlex on 12/25/24, 10:13 AM
If you have photosensitive migraine or epilepsy, stay the hell away from those demos.
by dsp_person on 12/25/24, 3:55 AM
by c22 on 12/25/24, 7:50 AM
by op00to on 12/26/24, 4:25 PM
by brcmthrowaway on 12/25/24, 4:35 AM
by amelius on 12/26/24, 5:27 PM
> 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?
by kizer on 12/25/24, 6:10 PM
by londons_explore on 12/25/24, 4:26 PM
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.
by cmiller1 on 12/25/24, 9:50 PM
by Stevvo on 12/25/24, 11:52 PM