Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

    Not right now, but, soon-ish, we'll be able 
    to do that very well with HDR displays [...]

    flat and Trinitron CRTs should be trivial. 
Visually I think we're really close in most of the ways that matter, with advanced shaders like CRT-Royale.

However, there's an entire additional dimension missing from this discussion so far - latency. When paired with original game hardware up until the 16-bit era or so, CRTs offer close to a true zero latency experience.

It's not possible to recreate this with modern tech. When we add up everything in the stack (display, input drivers, everything) we're looking at over 100ms of lag.

http://renderingpipeline.com/2013/09/measuring-input-latency...

We're not totally without hope. As the (ancient!) article notes, higher refresh rate displays reduce many of these latencies proportionally. And for non-action games, latency doesn't matter too much in the first place.

    At come point it becomes Theseus' computer, 
    but, if the goal is to preserve the boat, 
    [CPLDs and FPGAs] work
Well, for some parts of the boat.


> However, there's an entire additional dimension missing from this discussion so far - latency. When paired with original game hardware up until the 16-bit era or so, CRTs offer close to a true zero latency experience.

It's hard to even match the input latency and general responsiveness of an NES hooked to a CRT TV with a composite cable with modern hardware, let alone something more-integrated.

My usual test is "is it very, very hard to get past Piston Honda on Punch Out?" Often, with an initial, naive set-up, it's nearly impossible. Get it dialed in a little and he becomes easy (if you spent like a billion hours playing that game as a kid, anyway). But with many display + computer + controller combos it's just impossible to get it close enough to right, no matter how you tune it.

That's my test because it's really easy to tell if the latency is bad, but if it is I'll find myself falling off things constantly in Mario, too, it's just harder to tell if I'm playing poorly or if the system's the problem. The NES is hard enough, add just a little latency and it's hellish.


Latency is one dimension. Another one is peripheral compatibility. Devices such as light pens and light guns are incompatible with LCDs. These peripherals depend on the timing information encoded by the raster scan of CRTs.

This means classic light gun games such as Duck Hunt for the NES are impossible to play without a CRT.


Doesn't duck hunt use an entire frame of black then white? You don't need raster scan emulation for that, just very low latency.

Edit: Apparently there is a 15kHz filter inside the light gun. So it's not really about beam accuracy or brightness, it's about pulsing at the right frequency.


LCDs aren't capable of pulsing at 15kHz. The twisting/untwisting of the liquid crystals is an electromechanical process and very slow (compared to a racing electron beam). Even though the fastest gaming LCD monitors claim a 360Hz refresh rate, they cannot get anywhere near this 2.8ms latency (implied) when going from black to white (0 to 100% brightness). Of course, the monitor manufacturers go to great lengths to avoid talking about it, so the whole industry is flooded with a bunch of marketing material to distract from the issue.


> LCDs aren't capable of pulsing at 15kHz.

Yeah, I know. But you don't need the LCD to pulse, you need the backlight to pulse.

An LCD might still have issues switching fast enough, but an HDR OLED tuned to 15kHz PWM might be able to handle it. If it was designed with minimum latency in mind of course. Most screens buffer a full frame and that won't work. But playing duck hunt doesn't require timing the actual beam as it sweeps across the screen. You just need to be displaying rows with a buffer that's no more than a few rows high, and have the rows flicker. Also many third party controllers don't care that much about the flicker.


Oh, with OLED you could probably design it to mimic the raster scan of a CRT perfectly, cascading the row and column signals along at 15kHz. The issue is, who is going to build that? I don't think Duck Hunt is too high on the priority list for OLED panel makers.

The really sad thing is that some day all of the CRTs will be dead and all of the expertise to build them too. The tooling and factories are already gone, so it's unlikely new CRTs will ever be built, unless some Ben Krasnow-esque super-hobbyist gets really passionate about it.


> Oh, with OLED you could probably design it to mimic the raster scan of a CRT perfectly, cascading the row and column signals along at 15kHz.

You could but it wouldn't have the same brightness as it sweeps so I don't know if that's good enough to trick a light gun by itself.

But I still think you shouldn't discount LCD. If you can get an LCD to switch a good fraction of the way in half a millisecond, and use the right backlight, you could make duck hunt work.

> The issue is, who is going to build that? I don't think Duck Hunt is too high on the priority list for OLED panel makers.

To trick the frequency filter might be too much effort, but the latency of having each row come along instantly might get some effort into it. Marketing loves low latency.


The low latency claimed by LCD marketers concerns narrow grey-to-grey transitions. Black to white remains as slow as ever.

The other issue is all of the other causes of latency along pipeline. The NES emits an composite video signal directly from its video chip, the PPU. This composite signal travels along a coax cable into the back of the TV where it’s split by the analogue circuitry into signals driving the luminance and colour, synchronized to the horizontal and vertical retrace. The whole process happens in less time than it takes to convert that signal into digital before it could even be sent to an LCD.

That is, before our LCD display even receives a frame it’s already on the screen of the CRT. The NES is explicitly designed around the NTSC timing structure, with the rendering in the PPU happening “just in time” to be sent to the CRT. There is no place in the NES to buffer a frame.


> The whole process happens in less time than it takes to convert that signal into digital before it could even be sent to an LCD.

While that's true, doing the conversion doesn't need to add more than a microsecond of latency.

> That is, before our LCD display even receives a frame it’s already on the screen of the CRT. The NES is explicitly designed around the NTSC timing structure, with the rendering in the PPU happening “just in time” to be sent to the CRT. There is no place in the NES to buffer a frame.

An LCD doesn't have to buffer a frame either. I believe there are models that don't. It can display as it receives, limited by the crystal speed which is still an order of magnitude improvement.


Current consumer LCDs, sure, but there's no realson a high-refresh-rate LCD couldn't emulate the flying spot of a CRT, and thus be compatible with light pens / guns.


The horizontal scan rate of a CRT TV is 15,625 Hz. Good luck getting an LCD to refresh that quickly.


In order for that to work, it’d need to be able to switch individual pixels in sequence, one at a time. The display panel would need to be designed for this - current panels aren’t, but as long as a screen position could switch to 100% in about 250ns, a sensor could tell precisely which pixel it’s looking at.


Liquid crystals cannot switch from 0 to 100% in less than 10ms, never mind 250ns. They’re electromechanical devices that need to physically twist/untwist to affect the polarization of light.

Contrast that with a CRT which uses a 25kV acceleration voltage to drive an electron beam up to 30% the speed of light (takes about 3.3 nanoseconds to travel 1 foot from the back of the CRT to the screen), which then strikes a phosphor that glows due to its valence electrons falling from excited states (which takes a few nanoseconds).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: