I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development.

“Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays.

Still the optimization in 4-6 is fun. Did the whole thing in 1-3 just because of an assumption that the buffer would not wrap around, and then it did and all that work became obsolete.

Games have redrawn everything on every frame for decades, certainly since GPUs became a thing. Memory speed is definitely not a concern. 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well.

On the other hand, of course, CPUs do have a complex system of several levels of caches, but that's not primarily because of (lack of) memory bandwidth but memory latency.

> 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well.

For Win32 and X11 at least the damaged region (or "invalid region") approach is still there and AFAIK recently (as in a few months ago) the modesetting driver for Xorg added the ability to use the damage regions when "TearFree" is enabled (this does server-side composition to avoid tearing - it is disabled by default) to only update the of the screen that changed instead of the entire screen.

Also i remember reading some time ago about some monitors being able to use partial frame data (the monitor "shadows" the frame) so that they can support faster updates.

I think the concept can also help with slow display tech like e-ink devices.

Games started redrawing everything because once you have a camera that rotates in 3D, the pixel reuse drops a lot vs one that pans over a 2D plane.

All modern web browsers still do tiling (at the compositing layer level). It's the only way to handle large layers and scrolling efficiently.

Some also implement partial redraw into the tiles to handle things like cursors blinking to avoid having to redraw the entire tile.

More like after shaders became a thing, and it hardly matters when it is an application runnning on the GPU that is responsible for actually drawing.

However it is still an issue if one wants to achive maximum performance, and it is done by only sending the vertices and textures to the GPU that are actually going to be visible.

Some modern game UI still use dirty draw tech.

If I recall correctly, the original Macintosh would go as far as telling the software which regions of a window had to be redrawn at any given time so the idea itself wasn't exactly new. The thing is that these optimizations required tradeoffs. Figuring out which tiles had to be updated required storing extra data and doing extra computations. Not only did you have to recognize the value of these techniques, you actually had to write the code in a way that did not slow things down (and design the levels so they would not slow things down).

Windows has had this[1] for as long as I remember as well, at least since Windows 3 days so I assume since the very beginning.

[1]: https://learn.microsoft.com/en-us/windows/win32/gdi/clipping

They needed the same info to do clipping (on both the Mac and Windows).

I think it is more interesting that the pipeline was invalidaterect/region => getevent => event was a draw event => draw region (or part of it). The getevent would only generate draw events if nothing more important was going (keyboard/mouse input, timer, message from other app/desktop accessory). It would also prioritize top windows first so you would only get a draw event for a window at the bottom once the windows above had no more dirty areas.

If you really knew what you were doing, you could short circuit this a bit and draw in your windows outside of draw event handling.

“Our memory is fast, so let us redraw everything” is a given. Our web APIs on the other hand are incredibly slow, so let us carefully track changes in a complicated runtime (or compiler) to avoid redundantly modifying properties in a tree.

>I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development.

Yes, it's you and your vaulted position of standing on the shoulders of those to whom these developments actually were ‘revolutional’. I equate the level of accomplishments from Id to be at the level of cavemen throwing rocks at the spaceship to cavemen buying insurance on TV levels of achievement.

If you weren't playing games in early 1997 then Quake started using voodoo cards, it's nearly impossible to understate the before vs after.

Carmack and id are responsible for at least 4 or 5, "I had no idea a computer could do that" moments for me.

> “Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays.

Tangentially related: Android still doesn't get this. Turn on the screen refresh flashes in the developer menu and then look a your static screen and be amazed who often android draws even though nothing changed.

With modern gpu pipeline and cost of cache misses compared to CPU cycle being what they are - it's almost certainly faster to redraw a few thousand sprites no matter what than to check what changed and redraw only a subset of them.

Energy efficiency is a separate matter.

That's not true at all

Iterate over 1000 objects doing ifs and draw let's say 50 of them vs dump them in VBO and call glDrawArrays every frame drawing all 1000 of them?

I'm willing to bet :)

The difference in time spent by GPU between drawing 1000 and 50 sprites is almost 0.

Is there another way? I've only done WebGL, so not familiar with Vulkan/Metal/DirectX/etc. - but in my experience you're clearing the screen and re-drawing everything every tick no matter what. If only for applying post-processing effects.

Updating buffers is of course a totally separate thing, and on that side I don't think anyone updates everything every tick, usually there's some sort of scene graph that knows about dirty transforms and their children, so only those get updated..

This is nonsense, Android always did "this". It always rerendered only damaged regions and even after switching to HW accelerated rendering, it still only rerenders changed views.

And the animation framework always just "scrolled" the view (or screen) when it could.

Ncurses does the same on text, just redraw what it changes. Reason? Think about slow terminals or modems.

When I developed a text-mode UI library (not using curses) with a friend in university for fun, we tested this on his actual terminal connected via serial cable. You'll notice unnecessary redraws very quickly that way. (Granted, piping the output through some throttling may have had the same effect, but there was something about writing modern code (even as students) and seeing it work on decades-old hardware :).)

TIL that Adrian Carmack isn't related to John Carmack. Weird.

They continue to be the only two Carmacks I’ve ever heard of.

What about Jazz Jackrabbit? That game had some seriously fluid VGA scrolling.

Came out in 1994, which more or less aligns with OP's "well into the 1990s" timeline.

In 320x200 or 320x240 VGA, you could had essentially the same trick for scrolling window over the VRAM, checkout Mode X VGA. The Allegro library had baked-in support for that, at least in the early 2000's.

I'm intensely weirded out to see that all of the classic Commander Keen games were developed-and-released between December 1990 and December 1991. That is a wild pace of graphical and gameplay development.

Check out the evolution from the first game: https://en.wikipedia.org/wiki/Commander_Keen_in_Invasion_of_...

To the last game: https://en.wikipedia.org/wiki/Commander_Keen_in_Goodbye,_Gal...

I was playing them at the time, as a young child, and I'd forgotten the pace at which things were apparently happening.

Not to mention: Wolfenstein 1992, Doom 1993, Doom II 1994, Quake 1996. Unbelievable pace.

The joke at the time was that if your machine was more than 6 months old it was obsolete. So many aspects of computers were developing at a breakneck pace it was almost impossible to keep up.

The Bates 4000

https://www.youtube.com/watch?v=_2yjjHzifL8

Yeah, I had a pretty new PC (my first one after heavy-heartedly switching from the beloved Amiga to the despised PC) when Doom was released, and all my friends would come over to play because it could run it full screen (older 386 and weaker 486 CPUs were not fast enough, so you had to reduce the size of the game screen and play with an ugly static border around it). Then just a few years later I installed the Quake demo and all I got to see was an error message. The PC had a pretty exotic IBM "Blue Lightning" CPU which was a "486SX3", i.e. it ran at 75 MHz internally, 25 MHz externally, and didn't have a built-in FPU - which was a requirement for Quake. So I realized it was time to upgrade to a Pentium CPU...

You say you've had your desktop for over a week? Throw that junk away, man, it's an antique.

We went from Wolf3D to Quake 3 in 7 years.

So from software Ray Casting to full 3D acceleration in that time period.

7 years ago from now we had Uncharted 4, it is behind were we are now but not as much as you would think.

And in some cases games have gone backwards, this video comparing Arkham Knight to Gotham Knights being a prime example:

https://m.youtube.com/watch?v=2L3hVUPSDGc

For comparison, a little over a month from now will be GTA 5's 10 year anniversary, and GTA 6 is still nonexistent. Who thinks the technology leap between 5 and 6 will be anything remotely like the difference between Wolf3D and Quake 3?

But also, only a few years after Wolf3D we got Toy Story in 1995, the first major CGI full feature film. Six years later in 2001 we got The Spirits Within, the first attempted full-feature photorealistic film (it hasn't aged well and it bankrupted the company at a cost of $137 million at the time). And now we live in an age where realtime graphics look better than pre-rendered CGI films from 20 years ago... which also includes Lord of the Rings come to think of it.

And somehow they managed this incredible pace of software development without modern tools like git, or probably any kind of revision control system even (RCS/CVS/ClearCase were available on Unix systems, but in the DOS world I don't think there was anything).

Fun fact, Doom was actually developed on a NeXTStation, so with a Unix based OS (and predecessor to modern day macOS).

>> And somehow they managed this incredible pace of software development without modern tools like git, or probably any kind of revision control system even...

It's not that hard when one guy is writing the rendering code, another doing game logic, one doing artwork, one level design, and one doing sound. Nobody is really stepping on anyone's toes.

Yes, that keeps people from stepping on each others' toes, but revision control systems are really useful even for a single developer working alone, just to track changes, make changes to try something out and be able to revert easily, etc. You can do all that of course by making a bunch of ".bak files by hand, but a modern revision control system makes it much easier.

Carmack talked about how they released those first games on the Lex Friedman podcast. Having a previous framework and pipeline seemed to help get them out really quick.

https://youtu.be/I845O57ZSy4

See also John Romero on the Tim Ferriss podcast a few weeks ago https://podcasts.apple.com/us/podcast/681-doom-legend-john-r...

He talked how they were always working on 2 games and would do a press release with a shipping date before they more or less even started lol

Romero just released a new book 10 days ago... Doom Guy: Life in First Person https://amzn.to/43M0rSg

Great book so far BTW. Man, Romero had an interesting/rough childhood, that's for sure.

The crazy part was also working 2 full time jobs essentially, 8 hours at softdisk then they would use those PCs at night for 8 hours to crank out their private games, also borrowing them on the weekends to get more work done.

I understand that they could work 16 hours a day, but I wouldn’t believe they can separate two businesses like that. I would have told the same thing though.

unmatched, other than Golden Axe DOS port shipped a month before first Keen :-)

Ha... look at that. Not bad at all! I wonder how many machines at the time could power through that? ;)

Talking about these little tile and scrolling tricks. Golden Axe on the Master System had to get around the sprite size limit by having the entirety of the graphics live on the background layer. This meant everything sat and moved in an 8x8 pixel grid. A neat little hack even if it made the whole thing a little chunky.

While I have a fondness for that game it really didn't come close to running as fluent as Keen on my 8MHz EGA machine at the time ;)

Not an original PC game, but the PC port of Caveman Ninja, VGA and also from 1991, was amazing. Smooth parallax scroll with tons of sprites in screen. It recently got a remake on Steam.

> best-looking PC platformer well into the 1990s

I think I'd pick Prince Of Persia, not to diminish Commander Keen a single bit but I always found PoP visuals and game dynamics unmatched for its time. I'm also getting biased for two reasons: I played PoP when I believe I was 7 years old and made a magic impression on me when I first played it and is also is my favourite platformer of all times. But of course PoP lacks of the scrolling at all which is Commander Keen's black magic.

There is a magic about the character movements in PoP. I recently replayed it—almost 30 years after I first played it. There is a fluidity in how the prince moves that is still impressive today.

I understand that Jordan Mechner put in a ton of hours rotoscoping the movements. (Example: https://www.youtube.com/watch?v=fCy8WqAgPbY)

On a tangent, Mechner is an incredibly talented (and in my opinion, severely underrated) game designer. "The Last Express" is a masterpiece, and wondrous in a different way.

> There is a fluidity in how the prince moves that is still impressive today.

Yes it is very impressive even today. Those tons of hours on rotoscoping paid off immensely. I haven't played "The Last Express" though I've seen some screenshots and looks a very nice game. Somehow the artwork resembles the style of Alphonse Mucha: https://en.wikipedia.org/wiki/Alphonse_Mucha

I'd say PoP is bland and stale in comparison, but that's probably because there's lots of animations going on in the background for Keen. And it is faster paced. I enjoyed PoP2 better compared to PoP. It had grander visuals, epic escape and puzzle scenes.