XScreenSaver also has a demo that simulates an analog tv instead of a monitor like this.
It’s called “XAnalogTV”: https://www.youtube.com/watch?v=VmM1KkFsry0&list=PLbe67PprBS...
Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
51–60 of 62 posts
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#52Earlier quoted context omitted.
The second one does not run for me on an iPhone X, but the first one does.
I can only speculate as to why because it's safari which i don't have. If the eval is throwing an exception it's probably something to do with the unicode encoding that packs 2 ASCII chars into each UTF16 surrogate pair - the second one ultilises slightly more of the 20bits available and some UTF16 implementations/interfaces are buggy. You could replace 'eval' with 'throw' and see if the output looks like sane JS
Output from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#53Earlier quoted context omitted.
CRTs have some really nice characteristics with moving content. If you're using an LCD or OLED display now, if you quick scroll or drag a window around you'll see you can't read the text while it's moving. CRTs are different though, they strobe in a way that means motion is always clear. While film lets you hide these artifacts with clever tracking and angles, it's very obvious with interactive video games. There are…
You should be able to read it on OLED, which has instant response time, especially if it's a fancier one with 120fps or black frame insertion. The issues are more likely to be with your eyes than the screen. LED has more motion blur and occasionally flickery blacklights to deal with.
A perfect 120Hz OLED is still over 8ms of blur (MPRT), a crt is closer to 1.5ms MPRT.
There also are almost no OLEDs the right size for PC gaming.
Hopefully as VR tech becomes mainstream, display tech can improve up to the 1.5ms mark.
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#54Earlier quoted context omitted.
CRTs have some really nice characteristics with moving content. If you're using an LCD or OLED display now, if you quick scroll or drag a window around you'll see you can't read the text while it's moving. CRTs are different though, they strobe in a way that means motion is always clear. While film lets you hide these artifacts with clever tracking and angles, it's very obvious with interactive video games. There are…
Very true. A project I'm working on involves some scrolling and animation on older hardware at 60Hz. Looks absolutely smooth on the CRT, but when emulated on a modern display there's always some kind of trailing/blurring.
Some older Zowie gaming monitors let you strobe the backlight at 60Hz to work with older software, as well as some modern TVs. It's quite fiddly to setup, but it can be worth it if you enjoy your old 60Hz locked games looking smooth.
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#55See also: http://avisynth.nl/index.php/QTGMC
I would not have expected an AVISynth reference in 2021. VFW for the win!
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#56Earlier quoted context omitted.
I can only speculate as to why because it's safari which i don't have. If the eval is throwing an exception it's probably something to do with the unicode encoding that packs 2 ASCII chars into each UTF16 surrogate pair - the second one ultilises slightly more of the 20bits available and some UTF16 implementations/interfaces are buggy. You could replace 'eval' with 'throw' and see if the output looks like sane JS
Output from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap
Hah, actually that code is correct (Although I realise it probably looks like gobbledygook :D) so it disproves my theory.
The code is mostly arithmetic, so the only thing I can see which could be implementation sensitive is the canvas fillStyle HSL string, which omits commas and spaces since the % postfixes are enough to delimit the saturation and luminance, but obviously this depends on the canvas interface implementation.
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#57I suspect (worry?) that a lot of folks miss out on the other thrill of physical CRTs... an experience that is as close to zero latency as is physically possible. This article breaks it down in wonderful detail: http://renderingpipeline.com/2013/09/measuring-input-latency... The TL;DR is that on a "modern" stack (USB, display buffering, etc) with a 60hz display you're looking at over 100ms of input latency. You can ro…
Yes, the same thing with telephone calls over copper. No latency. You could both talk at the same time, more immersive. I also remember vector displays first-hand.. those were pretty awesome. You're never going to get a vector graphics experience ever on an LCD because LCDs are rasterized pixels not a drawn line. No one will ever make a limited run of CRTs or vector monitors ever again, but I wish they would. People…
Resolution is rapidly reaching the point where it won’t be the limiting factor in properly simulating a vector display, at least in a “good enough” fashion. Similar to how resolution and refresh rate improvements are making it feasible to simulate a raster CRT.
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#58Earlier quoted context omitted.
Output from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap
Hah, actually that code is correct (Although I realise it probably looks like gobbledygook :D) so it disproves my theory. The code is mostly arithmetic, so the only thing I can see which could be implementation sensitive is the canvas fillStyle HSL string, which omits commas and spaces since the % postfixes are enough to delimit the saturation and luminance, but obviously this depends on the canvas interface implemen…
I looked into it and this turned out to be the problem exactly.
If you change the part of your code where you have
hsl(${i*120} 99%${K*99}%
hsl(${i*120} 99% ${K*99}%
Then it works in the versions of Safari that I tested; Safari 14.0.3 on macOS Big Sur 11.2.2 running on a MacBook Pro M1, and Safari on iOS 14.4 running on an iPhone X.
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#59Earlier quoted context omitted.
CRTs have some really nice characteristics with moving content. If you're using an LCD or OLED display now, if you quick scroll or drag a window around you'll see you can't read the text while it's moving. CRTs are different though, they strobe in a way that means motion is always clear. While film lets you hide these artifacts with clever tracking and angles, it's very obvious with interactive video games. There are…
You should be able to read it on OLED, which has instant response time, especially if it's a fancier one with 120fps or black frame insertion. The issues are more likely to be with your eyes than the screen. LED has more motion blur and occasionally flickery blacklights to deal with.
The issue with modern displays (OLED and LCD) is that they are sample-and-hold, which means that a frame will remain lit for its whole duration, leading to motion blur. Even a perfectly instantenous pixel response won't fix that.
Re: Simulating CRT Monitors with FFmpeg (Pt. 1: Color CRTs)
#60I suspect (worry?) that a lot of folks miss out on the other thrill of physical CRTs... an experience that is as close to zero latency as is physically possible. This article breaks it down in wonderful detail: http://renderingpipeline.com/2013/09/measuring-input-latency... The TL;DR is that on a "modern" stack (USB, display buffering, etc) with a 60hz display you're looking at over 100ms of input latency. You can ro…
Yes - that's a great point. Although from the article, it seems that most of the latency isn't down to the display, but to the CPU/GPU part of the chain?
Yes, about 2/3 of it comes from the software/hardware stack in your computer/console.
The remainder (a few frames' worth of latency) is from the display itself. There's something like a frame buffer inside the display if I understand correctly although implementations vary widely; some displays are good for gaming and some aren't.
If you have a chance to game with original 8/16-bit hardware with wired controllers on a real CRT it's such a treat. You can really feel the difference.