3 ms·

Input in NES is not lag's source. Input is only read once per frame. Today it is very simple and cheap to improve over old controllers. Lag comes from video. I

Input in NES is not lag's source. Input is only read once per frame. Today it is very simple and cheap to improve over old controllers. Lag comes from video. If you do not use FPGA emulators like Mister the video delay is enormous. I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV). Are you maybe referring to 10ms NETWORK packet delay? All TVs or projectors use buffers, and it takes time for information to travel around serial cables. Network delay is inconsistent, but electronic delay is not.

lloeki 6y ago
> Input in NES is not lag's source. Input is only read once per frame. That’s exactly what I said ;) By virtue of being a different platform, emulation introduces a lag that is just not present on the real hardware (and can’t be lower by virtue of literally being a wire to memory). USB alone often introduces an astoundingly high minimal floor on latency. > I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV). Yes I have measured it (on all my devices, accurately so) in order to minimise it as much as possible (I can work with but can’t stand latency, even in a terminal). Rock Band, which I used to be an avid player of, allows you to adjust a relative delay (audio and video separately), timewarping A/V so that all three are perfectly in sync relative to real-world input. > Network delay is inconsistent, but electronic delay is not. I agree (and agree to buffers as well), but by and large any modern device is far removed from being just electronic, from USB (USB 2.0 has a 125us polling loop for multiplexing, USB 3 is point to point so can fare much better at 30us, but even then there’s kernel context switch to read and process that data) to HDMI (packet based with loads of multiplexing), many things end up being surprisingly subject to soft-real-time firmware/software before it hits the display itself. Hard real time stuff probably exists because the specs now allow for it but good luck finding that in consumer space where it’s much easier (read: cheaper) to push a best effort implementation. But my point isn’t about the minutiae of lag source, it’s that the human brain is severely impacted by lag, can adjust to some extent but the cost is paid heavily at multiple levels and with various efficacy crippling consequences; and that Q3 and subsequent games have increasing numbers of facilities to create the illusion that everything happens in sync so that we’re not so impacted by it.
- donturner 6y ago
  > the human brain is severely impacted by lag The brain can compensate for lag/latency up to a point. Church organ players often have to deal with >100ms of delay between pressing a key and hearing the note produced through those big pipes. If you have an app which produces a sound when you tap on the screen, and there's a delay of say 70ms between tapping and sound being produced, it's easily possible to play in time with an external clock source, like a metronome, as long as the delay is fixed. In the 1968 paper "Response time in man-computer conversational transactions" actions which occurred within 100ms the human input were perceived as instantaneous. In my experience this holds true with musical instrument apps, although one must first learn how much latency is present in order to compensate for it when synchronising with other clock sources.

lloeki 6y ago

> Input in NES is not lag's source. Input is only read once per frame. That’s exactly what I said ;) By virtue of being a different platform, emulation introduces a lag that is just not present on the real hardware (and can’t be lower by virtue of literally being a wire to memory). USB alone often introduces an astoundingly high minimal floor on latency. > I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV). Yes I have measured it (on all my devices, accurately so) in order to minimise it as much as possible (I can work with but can’t stand latency, even in a terminal). Rock Band, which I used to be an avid player of, allows you to adjust a relative delay (audio and video separately), timewarping A/V so that all three are perfectly in sync relative to real-world input. > Network delay is inconsistent, but electronic delay is not. I agree (and agree to buffers as well), but by and large any modern device is far removed from being just electronic, from USB (USB 2.0 has a 125us polling loop for multiplexing, USB 3 is point to point so can fare much better at 30us, but even then there’s kernel context switch to read and process that data) to HDMI (packet based with loads of multiplexing), many things end up being surprisingly subject to soft-real-time firmware/software before it hits the display itself. Hard real time stuff probably exists because the specs now allow for it but good luck finding that in consumer space where it’s much easier (read: cheaper) to push a best effort implementation. But my point isn’t about the minutiae of lag source, it’s that the human brain is severely impacted by lag, can adjust to some extent but the cost is paid heavily at multiple levels and with various efficacy crippling consequences; and that Q3 and subsequent games have increasing numbers of facilities to create the illusion that everything happens in sync so that we’re not so impacted by it.

donturner 6y ago
> the human brain is severely impacted by lag The brain can compensate for lag/latency up to a point. Church organ players often have to deal with >100ms of delay between pressing a key and hearing the note produced through those big pipes. If you have an app which produces a sound when you tap on the screen, and there's a delay of say 70ms between tapping and sound being produced, it's easily possible to play in time with an external clock source, like a metronome, as long as the delay is fixed. In the 1968 paper "Response time in man-computer conversational transactions" actions which occurred within 100ms the human input were perceived as instantaneous. In my experience this holds true with musical instrument apps, although one must first learn how much latency is present in order to compensate for it when synchronising with other clock sources.