Seeing Carmack's thoughts on programming always reminds me that I have such a long way to go. When he was my age, he had already created DOOM and DOOM 2 (along with the wtf? r_sqrt trick).
Fun story: both ID and Epic started out making 2D games. When Tim Sweeny saw Quake for the first time, he literally gave up on gamedev because he thought he wouldn't be able to keep up with game tech. But, shortly afterwards a friend of Tim wrote a Quake-like 3D renderer as a fun project. Tim figured if that guy could do it, he could do it and went on the make Unreal.
One important insight into all of this is that, while there might not have been BSP renderers until 1995, the BSP rendering algorithm was probably 10-20 years old at that point.
Another good example of this is the Phong shading model. IIRC it was invented in the mid-70s, and some software rasterizers implemented it, but it didn't really make its way into graphics cards with fixed pipeline rendering until the mid-90s.
Graphics tech in the 90s and even early 2000s involved a lot of hardware and software catching up to theory from the 70s and 80s because we were finally getting enough compute power to make it worthwhile to use "approximate" rasterization-based algorithms in order to get real-time rendering.
I had to dig up my source for this. I did misquote. It was Wolfenstein that gave Tim a shakeup and it drove him from coding to management, not out of games.
> Did you think about doing a first-person shooter after their success with Wolfenstein 3D and Doom?
> TS: It was funny how we got to that point. When I saw Wolfenstein for the first time, that was truly shocking. I'd never envisioned that you could do 3D in a computer game; I don't know why.
> The research had indicated that you could do that for at least 15 years before that, but it was this 3D game with real-time texture mapping; you know, real-time bitmaps scaled up and displayed in 3D on the screen. It never occurred to me that you could actually write code to do that. It was just another lack of foresight there.
> But seeing that for the first time, I was like, "Wow, I'm totally not worthy. I need to get out of programming now, because I'm never going to be able to compete with this." So they just basically demoralized me into becoming a manager for a few years.
> Around 1994, James Schmalz had written this 3D texture-mapping code, and I was starting to think, "Hmm, maybe that's not so hard." So I started reading up on references there and experimenting with it, and it turns out that, yeah, it's just another piece of code that you can learn how to create.
Yup, in hindsight it's interesting because the key innovation was realizing that real-time 3D was possible.
The algorithms themselves (like 3D texture-mapping) are college third year problem set level difficulty to actually implement, but having the curiosity, courage, and ambition to be the first to do it real-time is huge!
The algorithms used in today's 3-d game engines are definitely more complex than something I'd expect a college student to do, but the state of the art has also progressed substantially since the 90's.
That is incredible. I think that with games in particular, it is very easy to feel like you will never bridge the gap between where you are and whatever current AAA game is doing. It's easy to forget that those games we compare to are made by huge teams. The smaller games that are created by individuals and small teams are the product of a lot of effort. One simply has to stay the course and understand that a game is not made overnight. Still, it can be discouraging.
https://www.beyond3d.com/content/articles/8/ for the history of it. The original author is still unclear, but that article digs back as far as Gary Tarolli at 3dfx/SGI (by way of Carmack, Abrash, and Terje Mathison)
The man is a legend. I remember using his little set of DOS utilities (things like stuffit.com [2]) back in the early 1990s, which I got from a friend whose dad was a colleague of his at Hydro. They were all written in assembly language, and were superb little extensions to DOS.