Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CRT simulation (2014)

piratehearts.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: CRT simulation (2014)

#21

Post by 6502nerdface »

tadfisher wrote: post #6

This technique is very important for emulation and simulating the look of early games. For example, the Genesis/Mega Drive did not support hardware alpha transparency. Many games (including the Sonic series) simulate the effect by alternating vertical lines, and relying on the "visual munging" of CRTs to produce a convincing effect. Here is a video that demonstrates the effect in Shinobi 3: https://youtu.be/YFOkbfpIl…

In addition to the physical characteristics of a cathode ray tube itself, there is an orthogonal set of visual artifacts that follow from quirks of the analog NTSC signal encoding, and in the case of the NES, certain technical compromises in the design of the picture processing unit (PPU) that result in "ragged" vertical lines and chroma/luma interference; see [1] for documentation and example images.

It would be cool to see an NES emulator that combined an accurate simulation of the PPU's quirky NTSC encoding logic (already present in some emulators) with the kind of CRT/phosphor-simulation shown in TFA.

[1] http://wiki.nesdev.com/w/index.php/NTSC_video

Re: CRT simulation (2014)

#22

Post by Animats »

It's not a CRT thing, it's a NTSC thing. He seems to be trying to emulate NTSC (analog broadcast TV) color, not RGB. NTSC color signals have much lower bandwidth than the intensity signal. You can only go through the entire color gamut about 10 times across the width of the screen. So, for NTSC emulation, you should convert each scan line from RGB to YUV, then low-pass filter the UV component, then reassemble. You'll now have sharp edges where the intensity changes and fuzzy edges where the color changes, just like crappy old NTSC devices. This is strictly a horizontal phenomenon - in the vertical dimension, adjacent scan lines can be completely different colors without artifacts.

Re: CRT simulation (2014)

#23

Post by 6502nerdface »

Animats wrote: post #22

It's not a CRT thing, it's a NTSC thing. He seems to be trying to emulate NTSC (analog broadcast TV) color, not RGB. NTSC color signals have much lower bandwidth than the intensity signal. You can only go through the entire color gamut about 10 times across the width of the screen. So, for NTSC emulation, you should convert each scan line from RGB to YUV, then low-pass filter the UV component, then reassemble. You'll…

I think TFA's also trying to emulate specifically CRT-related effects like phosphor glow/trails. Maybe sort of conflating NTSC and CRT effects into one "CRT simulation"

Re: CRT simulation (2014)

#24

Post by kragen »

bitwize wrote: post #10
fake-name wrote: post #4

While this is technically awesome, I'd much, MUCH prefer to play without all the visual munging. Nostalgia aside, CRTs didn't actually look that good originally . They weren't used for their visual effects, they were used because they were cheap and easy. Why would you actively make your content look shittier? I suspect if you went back, and offered the people developing these games the option to play them on a moder…

> Nostalgia aside, CRTs didn't actually look that good originally. They weren't used for their visual effects, they were used because they were cheap and easy. Why would you actively make your content look shittier? For the same reason Quentin Tarantino is pouring much of his personal fortune into a movie theater that will run films in celluloid only. For the same reason vinyl is making a huge comeback. People think…

Um, while someone might build a celluloid-only movie theater, I don't think it's going to be Tarantino. Celluloid is a high explosive, which is why it was abandoned in the late 1940s and early 1950s, and Tarantino has shown no signs of being suicidal.

Re: CRT simulation (2014)

#25

Post by fake-name »

drewolbrich wrote: post #7
fake-name wrote: post #4

While this is technically awesome, I'd much, MUCH prefer to play without all the visual munging. Nostalgia aside, CRTs didn't actually look that good originally . They weren't used for their visual effects, they were used because they were cheap and easy. Why would you actively make your content look shittier? I suspect if you went back, and offered the people developing these games the option to play them on a moder…

bashtian, I suggest that you disregard fake-name's criticism. Do whatever you think looks best to you, and stick with it.

To be clean, I think this is quite cool. Just, if you're going to release it, give me an option to turn it off.

Re: CRT simulation (2014)

#26

Post by burnte »

rasz_pl wrote: post #14
tadfisher wrote: post #6

This technique is very important for emulation and simulating the look of early games. For example, the Genesis/Mega Drive did not support hardware alpha transparency. Many games (including the Sonic series) simulate the effect by alternating vertical lines, and relying on the "visual munging" of CRTs to produce a convincing effect. Here is a video that demonstrates the effect in Shinobi 3: https://youtu.be/YFOkbfpIl…

>This technique is very important for emulation and simulating the look of early games Why? I dont see people emulating the look and feel of 1920 black and white film projection, or Edison sound cylinders. Its because quality was SHIT, just like CRT.

Actually, you DO see such emulations, just look at Instagram, or people using tube amps to get fuzier sounds, listening to vinyl records, etc. It recreates the sound/image one remembers from their youth and thus helps magnify the nostalgic effect, enhancing the emotional recollection.

Re: CRT simulation (2014)

#27

Post by herpaderpa »

tadfisher wrote: post #9
Aqwis wrote: post #2

Why the motion trails? The Mario example doesn't have them and I can't recall any extreme motion trails from my days of playing console games on CRT TVs.

The screenshots are exaggerated; you didn't notice them because they lag by only about a frame. They did in fact exist, because it took time for the phosphors to lose their excitation.

  > you didn't notice them
There are four lights.

http://en.wikipedia.org/wiki/Asch_conformity_experiments

...anyway, the apparent presence of the motion trails would depend heavily on a person's use of the brightness, contrast and saturation setting per each individual television set.

Re: CRT simulation (2014)

#28

Post by pdkl95 »

6502nerdface wrote: post #21
tadfisher wrote: post #6

This technique is very important for emulation and simulating the look of early games. For example, the Genesis/Mega Drive did not support hardware alpha transparency. Many games (including the Sonic series) simulate the effect by alternating vertical lines, and relying on the "visual munging" of CRTs to produce a convincing effect. Here is a video that demonstrates the effect in Shinobi 3: https://youtu.be/YFOkbfpIl…

In addition to the physical characteristics of a cathode ray tube itself, there is an orthogonal set of visual artifacts that follow from quirks of the analog NTSC signal encoding, and in the case of the NES, certain technical compromises in the design of the picture processing unit (PPU) that result in "ragged" vertical lines and chroma/luma interference; see [1] for documentation and example images. It would be coo…

Blargg's NTSC filters emulate NTSC artifacts such as the vertical jaggies and chroma bleed. These filters have been available in many emulators for quite a few years.

Also note that Blargg's filters are efficient integer-only CPU filters, as they are fast enough to not need a GPU.

http://slack.net/~ant/libs/ntsc.html (main page)

http://slack.net/~ant/old/ntsc-presets/ (lots of example images)

http://slack.net/~ant/old/ntsc-vs-palette/ (examples specifically about the color-"correction" that happens when using NTSC)

Re: CRT simulation (2014)

#29

Post by pdkl95 »

fake-name wrote: post #4

While this is technically awesome, I'd much, MUCH prefer to play without all the visual munging. Nostalgia aside, CRTs didn't actually look that good originally . They weren't used for their visual effects, they were used because they were cheap and easy. Why would you actively make your content look shittier? I suspect if you went back, and offered the people developing these games the option to play them on a moder…

In a lot of the older systems (this was VERY common on the NES and SNES), the designers utilized some very heavy-handed dithering under the assumption that the dithering would be blurred heavily by both the CRT and the NTSC encoding. As these images demonstrate, the colors are incorrect if you skip emulating the NTSC chroma bleed.

http://slack.net/~ant/old/ntsc-vs-palette/

It was also very common to assume there wou9ld be darkening from the scanline effect on arcade machines, leading to brightness problem in the emulation of some ames.

Re: CRT simulation (2014)

#30

Post by pdkl95 »

wtallis wrote: post #16
mrob wrote: post #13

Earlier quoted context omitted.

CRTs, even high end ones, always had poor image quality. CRTs did however have superb motion quality, and it's only very recently with strobed 120Hz/144Hz LCDs that LCDs have matched CRT motion quality.

In what respect do you think CRTs had universally inferior image quality: viewing angles, contrast, brightness, gamut, color accuracy, spatial resolution, or something else?

CRTs have significantly better motion and latency. The LCD ghosting problem is well-known, and while some more modern screen have minimized the problem, there can still be some ghosting errors depending on the input. Gamut doesn't matter when you have previous frames ghosting over thing

More importantly, LCDs buffer a least one frame. Many buffer 3-5 frames (!). This can be a serious problem playing for video games or other interactive uses if you need to rely on well under 100ms late4ncy. Rockband/GuitarHero is the canonical example of this problem, where they had to develop various types of adjustable latency compensation into the later games. Bad firmware can make this unpredictable, too; it is common for the firmware to select different algorithms based on the name of the input that you're using. (e.g. and LCD might buffer fewer frames if [[ $input_name =~ /game/ ]].

Post reply on HN