[HN Gopher] CRT Simulation in a GPU Shader, Looks Better Than Bl...
___________________________________________________________________
CRT Simulation in a GPU Shader, Looks Better Than Black Frame
Insertion
Author : bangonkeyboard
Score : 175 points
Date : 2024-12-25 01:26 UTC (21 hours ago)
(HTM) web link (blurbusters.com)
(TXT) w3m dump (blurbusters.com)
| dsp_person wrote:
| I tried the 120Hz demo but can't really tell there's any effect.
| Does it look cooler with 240Hz?
| sergiotapia wrote:
| FWIW I have the ASUS ROG Swift PG32UCDM 31.5" 4K UHD (3840 x
| 2160) 240Hz Gaming Monitor - a $1.3k monitor and also don't see
| anything different in the demo. Maybe I'm looking at the wrong
| thing. https://www.shadertoy.com/view/XfKfWd
| klausa wrote:
| Make sure your browser lets you refresh at those framerates.
|
| Safari by default caps animations other than scrolling at
| 60fps (I think?).
| zamalek wrote:
| This will let you know what your browser is allowing:
| https://www.testufo.com/framerates (it will also
| demonstrate the issue that the post is attempting to
| solve).
| a1o wrote:
| I only get an hyphen on the iPhone
| wrboyce wrote:
| I got 60fps/60Hz on mine (iPhone 16 Pro, iOS 18.2).
| KuzMenachem wrote:
| Just FYI, you can go to Settings -> Safari -> Advanced ->
| Feature Flags -> Prefer Page Rendering Updates near 60fps
| and switch it off to get 120Hz
| brcmthrowaway wrote:
| I just see a flickering image. What am I missing on iPhone?
| pfg_ wrote:
| ios limits browser framerate by default, you can try going to
| settings > apps > safari > advanced > feature flags > disable
| "prefer page rendering near 60hz" and see if that has any
| effect. you can test by going to testufo and seeing if it gets
| the right framerate.
| nyanpasu64 wrote:
| I'm still interested in a "selective MPRT" GPU or monitor
| setting, that only does black frame insertion on changed parts of
| an image and a "safety margin" around them. This should reduce
| flicker on non-moving portions of an image/still screen while
| keeping moving portions sharper. But this probably isn't useful
| for office tasks, perhaps video, and high-framerate gaming (but
| only games running at a lower FPS than the screen can
| (partially?) redraw).
| modeless wrote:
| Looks way more flickery than a real CRT at 120 Hz on an OLED
| phone. Maybe 240 Hz would be better.
|
| 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.
| user_7832 wrote:
| Just a mini-warning/FYI: running the 120hz test on my 60hz LCD
| IPad (Air 4) has caused that part of the screen with the crt
| effect to flicker even after leaving the demo. I don't know what
| might cause this but it's weird and worth a warning to anyone
| interested in trying this out.
|
| (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.)
| tverbeure wrote:
| This is a well known effect. LCD cells must be driven with
| alternating positive and negative values (of the same
| magnitude) to maintain an average neutral value, otherwise you
| get some kind of offset buildup that will result in flicker.
|
| If you alternate every other image with a different color
| value, you upset that balance.
|
| It will slowly rectify itself for most displays.
| Etheryte wrote:
| Thanks for explaining, I've run into this on my phone in
| other contexts and I was starting to think my phone screen is
| having its last days. Turns out it's expected? Usually I run
| into this when the screen brightness is at the lowest
| setting.
| immibis wrote:
| So Snow Crash[0] _does_ affect both humans[1] and computers!
|
| [0] https://en.wikipedia.org/wiki/Snow_Crash
|
| [1] https://en.wikipedia.org/wiki/McCollough_effect
| Muromec wrote:
| Damn it, now I have ro read another Stephenson book.
| bitwize wrote:
| Snow Crash is the Hackers (1995 film) of Stephenson's
| body of work. It's so aggressively 90s and cyber techno
| that it seems somewhat adorably cheesy in retrospect, but
| there's an audience of Z-ers who are just now discovering
| it, and what it means to be excited about technology the
| way we were back then.
| redox99 wrote:
| This looks REALLY good on a 240hz monitor. Much better than BFI
| (which I don't use because it's pretty bad on my monitor)
| stelonix wrote:
| Tried on my simple 60Hz PC screen and also on my phone with OLED
| screen and sadly, it's just a flickering image. Will try later
| this week on my friends' retrogaming setup. Looks promising
| c22 wrote:
| Can I use this to play Duck Hunt?
| grishka wrote:
| No. Light gun games rely on the fact that a CRT display will
| draw the picture on the screen pretty much at the same time
| it's generated by the console's video chip. Modern digital
| displays introduce all kinds of delays due to processing and
| buffering they do. Usually several frames worth. This shader
| can't do anything to fix that.
| taneq wrote:
| That said, I bet you could fake the electron beam position
| with a high frame rate display, a modified version of this
| shader, and some kind of calibration routine...
| grishka wrote:
| You don't really need to emulate the position of the beam,
| at least not for the NES light gun. When you pull the
| trigger, the game first makes the entire screen black for
| one frame, reading the sensor in the gun and checking that
| it doesn't detect any light, and on the next frame, a white
| box is drawn where a duck would be. If the gun does detect
| light on this frame, it's counted as a hit. That second
| check is performed while the frame with the white box is
| still being drawn because CRT phosphors decay fairly
| quickly. You could, in theory, work around this with an
| LCD/OLED display with a high enough refresh rate that it
| would make up for the buffering delays.
| MarioMan wrote:
| For the longest time, I thought this was the only limiting
| factor, but modern panels are low enough latency for it to
| work, yet still don't.
|
| 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.
|
| https://www.nesdev.org/wiki/Zapper#Light_Sensor
| IshKebab wrote:
| You wouldn't be able to get horizontal position.
| isoprophlex wrote:
| This probably goes without saying but...
|
| If you have photosensitive migraine or epilepsy, stay the hell
| away from those demos.
| blensor wrote:
| I assume some people will approach this as stupidly as I did.
|
| 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
| phafu wrote:
| I'm wondering if it would rather make more sense to emulate a CRT
| with a video projector and some shutter device (maybe a fan?) in
| front. Has anyone tried that yet?
| stuaxo wrote:
| I've thought for a while that we need to simulate how phosphorus
| face in and out, at the very least.
| ahartmetz wrote:
| Ignoring the heavy flicker, it seems to reduce motion blur even
| with the 120 Hz demo running on a standard 60 Hz display.
| Especially visible on the windows. It doesn't seem like it should
| work, but it does?
|
| 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.
| empiricus wrote:
| You need an 120hz display to run the 120hz demo. I am surprised
| to see that the movement is clearer with the shader. You can
| follow the objects and they are more stable/more clear.
| empiricus wrote:
| I appreciate the crazy high dpi very much. Because the text is
| super sharp, it helps with the focus. I am 48 and my eyes are
| not perfect. I look at screens for many hours every day and if
| the text is not sharp enough, I lose focus and everything
| becomes blurry. But super sharp and bright screens mean the eye
| can have a feedback loop for the correct focus distance.
| naoru wrote:
| This is better than BFI, although 120Hz demo on my screen looks
| like it's just alternating two or three parts of the image. Maybe
| there is a way to use fake interlacing to make it look
| convincing.
|
| 240Hz demo in 144Hz mode looks flickery but much more realistic.
| yincrash wrote:
| The 120Hz shadertoy works on the Pixel 8 (and hopefully other
| 120Hz Android devices) if you go to Developer Options and enable
| "Force peak refresh rate"
|
| I wonder if there's a way to ask Android Chrome to ask for 120Hz.
| yincrash wrote:
| Ah, the non-developer option setting to enable 120Hz on later
| Pixels is under "Settings"->"Display & touch"->"Smooth
| display". With that enabled, Chrome will use 120Hz if power and
| temperature settings permit it to.
| SushiHippie wrote:
| Thanks for the hint, I had this setting enabled, but it
| didn't look good on Firefox, but using chrome made it look
| good!
| vslira wrote:
| I'm a complete layperson on graphics and such, so please someone
| help me here: does this mean we're now able to simulate old video
| game visuals on crt? That would be the best Christmas gift ever
| mrob wrote:
| We're getting closer, but 480Hz is still too slow for a
| convincing simulation of phosphor decay. 1000Hz will probably
| be enough.
| londons_explore wrote:
| To me this highlights that none of my hardware (pc, phone laptop)
| can actually render anything at native screen resolution and not
| occasionally drop frames.
|
| 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.
| pavon wrote:
| Awesome. I find it so ironic that the main thing tempting me to
| buy to a high resolution high framerate monitor is the desire to
| better emulate a low resolution low frame rate CRT.
| schmidtleonard wrote:
| After HD, adding pixels/framerate/depth/brightness is like a
| clean house: it's hard to articulate the value proposition up
| front in a way that does it justice and it's easy to talk
| yourself out of going to the trouble, but once you have it you
| realize just how good it is.
| jtxt wrote:
| Nice! Does-this/can-this handle interlacing?
|
| https://en.m.wikipedia.org/wiki/Interlaced_video
|
| (Half vertical resolution, offset a bit every other frame)
| Hakkin wrote:
| I have an AOC Q27G3XMN and while I do get reduced motion blur
| from this, I also experience very bad color banding/shifting.
| Messing with some of the values in the script config makes it
| slightly better, and changing the overdrive setting on the
| monitor seems to affect it as well, but there is still pretty
| strong banding no matter what strength it's on. I tested on my
| phone (Pixel 8) and it works very well there without any banding
| or color weirdness, so I guess it's just something about this
| particular monitor that doesn't work well with this method.
| kizer wrote:
| Could someone explain the point to me? I read the post and still
| don't quite understand. I remember CRTs looked smoother when
| pixels were still noticeable in (o)led displays. Is it to
| effectively lower the frame rate?
| mrob wrote:
| It's to reduce sample-and-hold blur. Modern displays typically
| produce a static image that stays visible for the whole frame
| time, which means the image formed on your retina is blurred
| when you move your eyes. CRTs instead produce a brief impulse
| of light that exponentially decays, so you get a sharp image on
| your retina. Blurbusters has a good explanation:
|
| https://blurbusters.com/faq/oled-motion-blur/
| kristopolous wrote:
| Just start making CRTs again. There's clearly consumer demand
| runlevel1 wrote:
| I don't know if the market is big enough to offset the cost of
| setting up production again.
| BearOso wrote:
| I adapted this to a retroarch slang shader really quick, and I'm
| seeing some pretty persistent banding on 120hz to 60hz. It shows
| up obviously when scrolling the same direction as the fake beam
| scanout. If you take the shadertoy version and edit the scanout
| direction to left-to-right and fullscreen it, you can see it
| there, too. The perpendicular scanout and scrolling the demo uses
| by default disguises it pretty well.
|
| I guess you probably need a higher ratio for this to work really
| well.
| pipes wrote:
| Silly question, but what does slang mean, as in I've been using
| retro arch for years and have always wondered what slang means
| in relation to the shaders.
| cmiller1 wrote:
| Now add different phosphor decays on the black parts for each
| subpixel!
| akoboldfrying wrote:
| Can anyone explain why this requires a relatively high-end GPU?
| Looking at the slo-mo GIFs, it looks like `brightness *=
| SomeLUT[(y + t) % sizeOfTheLUT]` for each colour channel would do
| the trick.
|
| What makes it so complicated?
___________________________________________________________________
(page generated 2024-12-25 23:00 UTC)