4 ms·

> Additionally, Ware explained that the refresh rate on an LCD may not play well with an old game’s code that is expecting a much more responsive CRT monitor. I

> Additionally, Ware explained that the refresh rate on an LCD may not play well with an old game’s code that is expecting a much more responsive CRT monitor. It could cause unsightly screen tearing that looks like one half of the screen is occasionally redrawing before the other. Does this really happen with LCD arcade monitors? It happens with PC-based emulators because they usually can't make the OS/drivers/GPU/monitor switch to a refresh rate that matches the emulated hardware (which, despite the quoted "more responsive CRT" bit, is just as likely to be below 60 Hz as above it, and usually not by a large amount either way) but I don't see how CRT vs. LCD is a major factor if we're talking about monitors that are actually made for arcade machines.

donatj 10y ago
Many games knew exactly where the beam was and played tricks on your eye. These don't translate well to LCD.
- matthewwiese 10y ago
  Bogost & Montfort's Racing the Beam (https://en.m.wikipedia.org/wiki/Racing_the_Beam https://en.m.wikipedia.org/wiki/Racing_the_Beam) is about that very practice, though concerning the Atari 2600 in particular.
  - mgkimsal 10y ago
    Loved that book! Loved all the behind-the-scenes stories and the deep-dive in to some of the tech issues (it was past my ability to comprehend it all, yet "not enough detail" for a friend of mine).
- 0xcde4c3db 10y ago
  Are there many that actually depend on syncing up to the physical refresh and not just fiddling with registers at the right point in signal/pixel space? The only thing I can think of is some old-school light gun games, which involve a physical sensor pointed at the screen and thus depend on sufficiently high brightness and sufficiently low input lag (and so almost always fail on LCDs).
nitrogen 10y ago
In addition to the other comments, some digital displays can only run at a fixed rate, and any input faster or slower than that rate gets juddery. I had an old DLP projector once (sadly, stolen) that had to be run at exactly 61.67Hz to match the color wheel speed.
to3m 10y ago
Yes, this seemed unlikely to me as well. If the pixel clock is fixed, there's no other signal to display other than the one you'd see on a CRT... maybe people use some hardware that has some kind of framerate conversion step that introduces artefacts?

donatj 10y ago

Many games knew exactly where the beam was and played tricks on your eye. These don't translate well to LCD.

matthewwiese 10y ago
Bogost & Montfort's Racing the Beam (https://en.m.wikipedia.org/wiki/Racing_the_Beam https://en.m.wikipedia.org/wiki/Racing_the_Beam) is about that very practice, though concerning the Atari 2600 in particular.
- mgkimsal 10y ago
  Loved that book! Loved all the behind-the-scenes stories and the deep-dive in to some of the tech issues (it was past my ability to comprehend it all, yet "not enough detail" for a friend of mine).
0xcde4c3db 10y ago
Are there many that actually depend on syncing up to the physical refresh and not just fiddling with registers at the right point in signal/pixel space? The only thing I can think of is some old-school light gun games, which involve a physical sensor pointed at the screen and thus depend on sufficiently high brightness and sufficiently low input lag (and so almost always fail on LCDs).

nitrogen 10y ago

In addition to the other comments, some digital displays can only run at a fixed rate, and any input faster or slower than that rate gets juddery. I had an old DLP projector once (sadly, stolen) that had to be run at exactly 61.67Hz to match the color wheel speed.

to3m 10y ago

Yes, this seemed unlikely to me as well. If the pixel clock is fixed, there's no other signal to display other than the one you'd see on a CRT... maybe people use some hardware that has some kind of framerate conversion step that introduces artefacts?