You seriously should to leave the computer, come back tomorrow, and then reread these posts. You are trying to stomp on someone's fond memory of a simple problem that they solved in a way that was novel to them. They clearly don't think that they are deserving of a Turing award, they were just young and felt some pride.

Not really arguments. Otherwise, I also do here "the same principle" as Platon and Aristotle as I discuss anything with you. And I'll have the fond memories of this. Don't stomp on them.

My claim is that anybody who thinks moving the text cursor is "the same principle" as Carmack's one pixel at the time smooth scrolling doesn't have elementary understanding of both. And I explained the difference.

I have nothing against morgawr writing about his discovering cursor positioning. I have against supporting him equating this with something completely different. If a five year old goes out of the go cart and says "ma I can ride the plane" nobody cares. If he's 20 something and claims the same after the same "feat" on the pilot forum, some pilot can try to correct him, even if it's the lost time. Even if he also knows that there's the famous "don't argue with .... People might not know the difference."

I still think it was worth writing these comments.

Not really. Dirty rects are dirty rects! And anybody familiar with coding for crappy systems that sported hardware scrolling would use the same technique, because your options are limited when the screen moves due to base address changing and yet you want in-memory sprites (i.e., bits copied into screen memory by software or hardware, rather than images drawn automatically at a particular position during the scan) to move independently while drawing nicely on top of the background. And for full-screen scrolling games it is usual for at least the player sprite to stay centred. BBC Micro examples from the 1980s would include JCB Digger, Uridium and Firetrack. I bet Atari ST and Amiga games did the same thing too; the principle extends obviously to multi buffering.

The cunning part of the Carmack games was presumably widening the screen - I don't think I ever saw this done on the BBC. But as a schoolboy in 1989/1990 I'd experimented with reducing the BBC's screen height by one character row (by tweaking R6) to avoid flicker when scrolling vertically. Same principle. It's a fairly obvious thing to do, once you've figured out what's going on.

I think one can come up with better evidence for John Carmack's uniquely amazing skills.

My own understanding was that it was just that particular configuration of the EGA hardware that hadn't been tried before Carmack's implementation.

This is someone who found out from Romero exactly what the Keen games did: http://www.vintage-computer.com/vcforum/showthread.php?30619...

You discuss Carmack's pixel scrolling and miss the fact that this guy here who claims he did "the same" just had to draw one character of the snake's head at the new position, overwriting the previous head with the "body" character. And the tail character with the "empty" character unless the snake eats something.

What in the world has that to do with Carmack's algorithm of updating Mario after one pixel hardware scroll (after which he has to redraw the "unmoving" part fully) and adding more background once he spends the hardware moves?

Same principle, as I see it, whether it's writing 1 byte, calling gotoxy/putch, or copying a whole bunch of bytes. Dirty rects! The insight is the same: you draw the things that have changed, and leave alone the things that stay the same.