> "However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing."

Nicely put. :) Thanks for the link.

After many years of programming, I came round to favour more inlining than I used to (I probably wouldn't go as far as some of this function, however).

Needlessly increased variable scopes - and thus increased risk of harder to follow cross-dependencies - is probably the biggest downside risk. But I've found code that executes linearly easier to read and understand when it's written linearly. When everything is factored into functions - particularly impure functions - you need to click all over the place to understand the whole.

If there are higher-level primitives that can be used - filters, maps, folds, etc. - then they can reduce the verbosity overall. Some monadic styles can flatten nested code by computing a pipeline / computation rather than having lots of nested loops. But depending on the language and the problem domain, performance may suffer.

For me, this code looks like it was decompiled. It's pretty much this amount of insanity.

> When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).

This is a great piece of advice and one that has worked for me in the past when refactoring code like the one referenced.

    I was quite surprised at how often copy-paste-modify
    operations resulted in subtle bugs that weren't
    immediately obvious.

    I now strongly encourage explicit loops for everything,
    and hope the compiler unrolls it properly.

I found this particularly interesting

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.

Is this true? There's leaked Unreal alpha stuff from 1995, which was already doing almost everything Quake's bsp renderer ended up doing.

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.

http://www.gamasutra.com/view/feature/4035/from_the_past_to_...

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.

I don't believe he wrote the original fast inverse square root trick; but he is no less an inspiration for it.

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)

Nitpick: Terje Mathisen [1].

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.

[1] https://www.linkedin.com/in/terje-mathisen-b740181

[2] http://files.mpoli.fi/unpacked/software/dos/utils/keyboard/s...

Heh, Terje's name is actually misspelled in the linked doc (I was like "I know I copy/pasted that")

Really interesting. I already began to inline code with a comment for each block. Didn't knew John Carmack agree with me.