5 ms·

A few months ago I found my old GameBoy and played through part of "Kirby: Nightmare in Dreamland". I know its not the most well-known game, so the relevant det

A few months ago I found my old GameBoy and played through part of "Kirby: Nightmare in Dreamland". I know its not the most well-known game, so the relevant detail is that it relies a lot on timing and quick movements. I was completely blown away by the responsiveness of the controls. The control feedback was instant, frames were rock-solid, and there were no loading screens at all. When I put down the game, I was just tremendously sad. I'd forgotten what instant feedback felt like.

dahfizz 6y ago
It really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time. You just can't get that responsiveness anymore.
- yjftsjthsd-h 6y ago
  Wait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.
  - ce4 6y ago
    The NES-CRT connection is analog and the screen is drawn line by line, if you connect a digital monitor that will have to be buffered and you get some delay/lag of min 1 frame.
    - mrob 6y ago
      Most LCDs only buffer a single line at a time: https://www.youtube.com/watch?v=wts8f1bNnbo https://www.youtube.com/watch?v=wts8f1bNnbo
      - formerly_proven 6y ago
        You misunderstand the video. A LCD controller must buffer at least one line, because the LCD matrix is updated line for line, all columns in parallel -- it's a matrix, much like a RAM matrix. However, the video just shows how the LCD is scanned out, it doesn't say anything about the buffering of the controller. A lot of non-gaming LCDs, and virtually all older non-gaming LCDs, buffer an entire frame, even if they are driven in their native mode.
  - bloaf 6y ago
    For an interesting discussion: https://www.reddit.com/r/smashbros/wiki/lag https://www.reddit.com/r/smashbros/wiki/lag
  - nwallin 6y ago
    It's not so much that CRTs are faster than LCD. It's that old consoles (up until the Sega Saturn, Nintendo 64, Sony Playstation era) didn't draw to frame buffers. They didn't have enough RAM to have a real frame buffer. You configured the graphics chip what you wanted it to draw, and as the scanline scanned across the screen, it outputted the color that was supposed to be output depending on the background/sprite/palette settings. You could change where the sprite is halfway across the scanline, and it might immediately, in the middle of drawing a scanline, output a different color. There was no delays anywhere in the system, only the propagation delay of electricity in wires and transistors. The various HW registers that controlled what and where the sprites were were connected via a small pile of non-clocked digital logic gates to a DAC to the analog output pins of the graphics chip, which was connected to the electron guns directly if you used component video or via a simple, no-latency analog circuit if you had composite video. These days, you program the graphics card to draw what you want it to draw. Once you've programmed everything for it to draw, it draws that into the backbuffer. Once the current frame has been sent to the display, the backbuffer is swapped with the frontbuffer. When the next frame begin is sent to the display, your changes finally go out across the wire. Depending on the display (see especially motion adapting TV screens) there might be more delay. Then whatever changes you make are finally displayed on the screen. It's kinda weird. Old video game consoles (up until the SNES and Genesis) had extremely low latency. And that's been gone for 25 years. Not only is it gone, but it will likely be gone forever- we don't even make the technology anymore to show the new generation what it was like. On the one hand, the new technology is "better"; there's no way to do today's advanced graphics without a deep drawing pipeline that outputs to a frame buffer. But it's also somehow worse. We can make it less bad with technology like 144Hz and Freesync, but the old era is gone.
    - minerjoe 6y ago
      Thank you for this. I started on the Apple II and i'ts been downhill since then. If I remember correctly the Apple II has one of the smallest latency between touching a key and seeing the result on the screen.
    - ponker 6y ago
      Does n64 have a frame buffer?
  - Kuinox 6y ago
    CRT have latency in the nanosecond. Best LCD screen says they have 1ms latency.
  - formerly_proven 6y ago
    The scan speed is exactly the same for all screens when driven by the same timings (resolution, blanking, refresh rate), so there is no difference there. Most digital screens have some processing lag, for gaming screens usually 1-4 ms. This doesn't exist in a CRT. LC panels have a pixel response time, somewhere around 1-40 ms depending on the color change, drive mode and panel type ("1 ms" is always a grey-to-grey transition and generally with overdrive). CRT phosphor lights up practically instantly when hit by the electron beam. So for a given set of timings, you'd always expect the CRT to be faster, because it represents the absolute minimum time-of-flight delay, assuming it is driven by a direct RAMDAC and not by a conversion box buffering an entire frame or significant portions. Also, you can "move" electron beams at extremely high speeds. Even in a magnetic deflection CRT like the GDM-FW900 the electron beam can move at more than 80 km/s[1]. In some electrostatic deflection systems the speed of light is exceeded: they can draw a dot moving across the face of the CRT that moves at a higher speed than c. This is possible because "the beam" is a fictional object. [1] 2304 dots across 482 mm with a pixel clock of around 384 MHz means these 2304 dots are covered in about 6 µs; 482 mm/6 µs = 80.3 km/s.
- cjsawyer 6y ago
  How does that compare to 144hz 1ms response gaming monitors? I know that late CRT’s handily beat early flatscreens but does that still hold?
  - Ijumfs 6y ago
    You don't have to believe these claims you know. And you need to add up all the latencies of all the components in the chain, from your keyboard and mouse to DirectX or whatever it is...
  - fxtentacle 6y ago
    For a PC, you'll most likely have USB latency, double-buffering, latency between the graphics card and the screen, latency due to picture processing in the screen. All that is additional to the 1ms that the pixels need to switch color after the instruction to do so has been received.
    - correct_horse 6y ago
      In addition to these excellent points, the "1 ms" pixel response time is measured grey to grey i.e. favourable to the display and not real-world. The bigger problem with advertised pixel response times is there is no industry standard measurement procedure (which grey to which grey?, is hdmi processing latency counted?), so pixel response times are vague, mostly useless marketing.
agumonkey 6y ago
I think it says something about human interfaces. When I run old linux 2.4 distros, even if everything is crude (GUIs redraw without double buffering, no compositor nothing).. no font AA .. yet it feels 'better'. And it's not nostalgia only.

dahfizz 6y ago

It really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time. You just can't get that responsiveness anymore.

yjftsjthsd-h 6y ago
Wait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.
- ce4 6y ago
  The NES-CRT connection is analog and the screen is drawn line by line, if you connect a digital monitor that will have to be buffered and you get some delay/lag of min 1 frame.
  - mrob 6y ago
    Most LCDs only buffer a single line at a time: https://www.youtube.com/watch?v=wts8f1bNnbo https://www.youtube.com/watch?v=wts8f1bNnbo
    - formerly_proven 6y ago
      You misunderstand the video. A LCD controller must buffer at least one line, because the LCD matrix is updated line for line, all columns in parallel -- it's a matrix, much like a RAM matrix. However, the video just shows how the LCD is scanned out, it doesn't say anything about the buffering of the controller. A lot of non-gaming LCDs, and virtually all older non-gaming LCDs, buffer an entire frame, even if they are driven in their native mode.
- bloaf 6y ago
  For an interesting discussion: https://www.reddit.com/r/smashbros/wiki/lag https://www.reddit.com/r/smashbros/wiki/lag
- nwallin 6y ago
  It's not so much that CRTs are faster than LCD. It's that old consoles (up until the Sega Saturn, Nintendo 64, Sony Playstation era) didn't draw to frame buffers. They didn't have enough RAM to have a real frame buffer. You configured the graphics chip what you wanted it to draw, and as the scanline scanned across the screen, it outputted the color that was supposed to be output depending on the background/sprite/palette settings. You could change where the sprite is halfway across the scanline, and it might immediately, in the middle of drawing a scanline, output a different color. There was no delays anywhere in the system, only the propagation delay of electricity in wires and transistors. The various HW registers that controlled what and where the sprites were were connected via a small pile of non-clocked digital logic gates to a DAC to the analog output pins of the graphics chip, which was connected to the electron guns directly if you used component video or via a simple, no-latency analog circuit if you had composite video. These days, you program the graphics card to draw what you want it to draw. Once you've programmed everything for it to draw, it draws that into the backbuffer. Once the current frame has been sent to the display, the backbuffer is swapped with the frontbuffer. When the next frame begin is sent to the display, your changes finally go out across the wire. Depending on the display (see especially motion adapting TV screens) there might be more delay. Then whatever changes you make are finally displayed on the screen. It's kinda weird. Old video game consoles (up until the SNES and Genesis) had extremely low latency. And that's been gone for 25 years. Not only is it gone, but it will likely be gone forever- we don't even make the technology anymore to show the new generation what it was like. On the one hand, the new technology is "better"; there's no way to do today's advanced graphics without a deep drawing pipeline that outputs to a frame buffer. But it's also somehow worse. We can make it less bad with technology like 144Hz and Freesync, but the old era is gone.
  - minerjoe 6y ago
    Thank you for this. I started on the Apple II and i'ts been downhill since then. If I remember correctly the Apple II has one of the smallest latency between touching a key and seeing the result on the screen.
  - ponker 6y ago
    Does n64 have a frame buffer?
- Kuinox 6y ago
  CRT have latency in the nanosecond. Best LCD screen says they have 1ms latency.
- formerly_proven 6y ago
  The scan speed is exactly the same for all screens when driven by the same timings (resolution, blanking, refresh rate), so there is no difference there. Most digital screens have some processing lag, for gaming screens usually 1-4 ms. This doesn't exist in a CRT. LC panels have a pixel response time, somewhere around 1-40 ms depending on the color change, drive mode and panel type ("1 ms" is always a grey-to-grey transition and generally with overdrive). CRT phosphor lights up practically instantly when hit by the electron beam. So for a given set of timings, you'd always expect the CRT to be faster, because it represents the absolute minimum time-of-flight delay, assuming it is driven by a direct RAMDAC and not by a conversion box buffering an entire frame or significant portions. Also, you can "move" electron beams at extremely high speeds. Even in a magnetic deflection CRT like the GDM-FW900 the electron beam can move at more than 80 km/s[1]. In some electrostatic deflection systems the speed of light is exceeded: they can draw a dot moving across the face of the CRT that moves at a higher speed than c. This is possible because "the beam" is a fictional object. [1] 2304 dots across 482 mm with a pixel clock of around 384 MHz means these 2304 dots are covered in about 6 µs; 482 mm/6 µs = 80.3 km/s.
cjsawyer 6y ago
How does that compare to 144hz 1ms response gaming monitors? I know that late CRT’s handily beat early flatscreens but does that still hold?
- Ijumfs 6y ago
  You don't have to believe these claims you know. And you need to add up all the latencies of all the components in the chain, from your keyboard and mouse to DirectX or whatever it is...
- fxtentacle 6y ago
  For a PC, you'll most likely have USB latency, double-buffering, latency between the graphics card and the screen, latency due to picture processing in the screen. All that is additional to the 1ms that the pixels need to switch color after the instruction to do so has been received.
  - correct_horse 6y ago
    In addition to these excellent points, the "1 ms" pixel response time is measured grey to grey i.e. favourable to the display and not real-world. The bigger problem with advertised pixel response times is there is no industry standard measurement procedure (which grey to which grey?, is hdmi processing latency counted?), so pixel response times are vague, mostly useless marketing.

agumonkey 6y ago

I think it says something about human interfaces. When I run old linux 2.4 distros, even if everything is crude (GUIs redraw without double buffering, no compositor nothing).. no font AA .. yet it feels 'better'. And it's not nostalgia only.