Dev.SN ♥ developers
Sections
Dev.SN
Anonymous Coward writes:
Two years ago John Carmack tweeted, "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f'd up is that?" And if this weren't John Carmack, I'd file it under the interwebs being silly.
Not convinced? You aren't alone, but Carmack appeared when called out to defend this claim.
We looked further and found this informative article from AnandTech about input lag.
This discussion has been archived.
No new comments can be posted.
Transatlantic Ping Faster than Sending a Pixel to Screen
|
Log In/Create an Account
| Top
| 1000 moderator points
| 17 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth.
-- Fry
(Score: 1, Insightful) by alioth on Friday March 28 2014, @06:39AM
On my 1982 Sinclair Spectrum (with a Z80 CPU running at 3.5MHz) I can send a pixel to the screen much faster than that. (In fact I can get the entire screen updated in under 20ms, a transatlantic IP packet takes about 60ms).
The fastest I can send a pixel to the screen on said computer would be something like this program, which will set the top left pixel on the screen:
ld a, 0x80
ld (0x4000), a
This takes approximately 5 microseconds.
(Score: 5, Informative) by Anonymous Coward on Friday March 28 2014, @08:00AM
> The fastest I can send a pixel to the screen
> on said computer would be something like this
> program, which will set the top left pixel on
> the screen:
>
> ld a, 0x80
> ld (0x4000), a
>
> This takes approximately 5 microseconds.
That doesn't send a pixel to the screen, it only
updates memory that represents the screen. To
actually see the new pixel, the electron gun in
your CRT has to sweep through that pixel. That
will take somewhere around 8 milliseconds, with a
worst-case around 17 ms.
Your fast update also excludes the whole "read
user input and figure out what to do with it"
part. TFA suggests ~10-100ms for that on a modern
computer; I'd guess 2-5x that on your Sinclair,
for a contemporary game.
TFA argues that there's maybe 20 or so ms of lag
associated with transmitting a frame to an LCD and
actually displaying that frame, lag which is not
present in direct-drive CRTs, but is really a
small part of the user-input-screen-update cycle.
(Score: 0) by Anonymous Coward on Friday March 28 2014, @09:24AM
I wouldn't be so sure about that. I don't know about the sinclair, but on the C64, the keyboard was laid out (electronically) in an 8x8 matrix, connected to two memory mapped 8 bit parralel ports. Although you do say "game", which is completely different from Carmacks test. For his test, which only needs to poll one key, you could set up one port ahead of time to the correct row (assuming interrupts disabled), after which polling the port is a single instruction plus a branch if the port read as zero. Updating the screen background color is a third instruction. Along with a jump back to the test, that's four instructions for the entire test routine (after setting up everything), and the jump is not time critical.
Even with 1 MHz, three instructions is pretty fast.
(Score: 2) by Koen on Friday March 28 2014, @11:24AM
And thanks to Z80's LDIR (load, increment & repeat) instruction one could send whole screens (or parts of it) very fast.
/. refugees on Usenet: comp.misc [comp.misc]