Quake's 3-D Engine: The Big Picture by Michael Abrash (2000)
bluesnews.com
bluesnews.com
I feel like he hasn't been risen up to the stature of John Carmack but if you look at the things he's shipped in his career (no less than Quake AND Windows NT) and at the sheer volume of content he produced during those halcyon days in the late 80s/90s when the PC emerged from dumb as rocks beige business box to premier gaming platform, he is a key figure.
I was too young and grew up too remote to have access to his writings as they were written but as an older engineer going back over his Graphics Black Book, the Zen of Assembly books and his Dr Dobbs articles, there's a lot of lessons that you can learn that still have a lot of value today.
Actually one of the best lessons - and most easily accessible - is in the first chapter of his graphics black book, he talks about the human element of optimisation, and that it is critical to optimise the right thing. He uses an example of a engineer he knew that in the era of early electronic calculators (still clunky and and slow, but getting faster all the time) honed his slide rule skills to wipe the floor with any desktop calculator operator. But he was spitting into the wind, it was clear calculators were getting faster and there was no more road with slide rules.
Ultimately he wasted effort on a legacy technology rather than leveraging what was up and coming.
In many ways this mirrored the PC, in its early days, it was slow, dumb and unwieldy, but it was improving at a rate of knots and eventually came to dominate.
Both Michael's Black Book and Zen of Assembly are on Github and maintained as PDF, Epub and other formats. They aren't terribly applicable technologically to computing today but they are very readable and contain a lot of general purpose problem solving and optimisation tips that are as applicable today as they were then.
https://github.com/jagregory/abrash-black-book
There have been few technical writers emerge that match Michael Abrash and it makes me so happy he's still hacking away at interesting problems today. Shame he doesn't write as much as he did, but I'm sure he's busy trying to usher in the metaverse (snowcrash had a big influence on him)!
What I found really remarkable, though, was he also picked my brain -- a junior programmer with no notable accomplishments, working on not very interesting problems. And when I bumped into him on a couple occasions after that, he remembered what I worked on and would ask how it was going.
If Michael can remember your details, he'll surely remember all kinds of other details as well and have them at his command.
https://www.gdcvault.com/play/1014236/Quake-A-Post-Mortem-an...
And who crashed that car? Was it Jeff R. ?
Do you know of a source for Dr Dobbs too? I've found this so far [0] but no luck yet with more recent volumes.
I wish I could meet him one day but I expect my brain would empty out and I'd just stay there nerd-giggling and gushing.
"The best optimizer is between your ears!"
"After you finish the first 90% of a project, you have to finish the other 90%."
I feel like this conflict is reconciled today by releasing the first 90% and the second 90% as updates.
Notably, QTest was released on February 24, 1996, followed on June 22, 1996 by the full Quake release.
Damn, I feel like you just described everything wrong with the game industry in the last 5-10(?) years in one sentence.
Even the maligned Day-0 mega-patch, is fine if it lets the game master ship earlier and fixes the bugs before I can play it.
Which makes sense because it's how much we've been online first.
Games before that era usually worked under the assumption that an internet connection (or at least a higher bandwidth one) wasn't available. Nowadays there's barely any reason to stop development after the GM is being burned on disks.
I do wonder what's gonna happen with long term use though. My game boy cartridges still work, but what will happen with current gen games? Even those bought phisically usually depend on patches from a server that won't be available in the long term future.
See also https://fabiensanglard.net/ for a more contemporary take. His 'Black Books' on Wolfenstein and Doom are directly inspired by Abrash.
i = * (long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - (i >> 1); // what the fuck?Carmack's code is something I've always admired. The system he figured out for a client/server networking model in Quakeworld for Quake 1 is still essentially the way most multiplayer games work now, as far as I know.
Was some controversy as people said it makes it easier to write cheats, I remember even Cliffy B from Epic Games wrote this blog post about how terrible it is but that is where games went and IMO its a lot better then 1990s netcode.
The main difference between the two model format was how they encoded vertex coordinates. They both stored X, Y, Z coords as one byte each. But MDL (Quake 1's format) had a uniform scale/offset for transforming these into the final coordinate space, whereas in MD2, each animation frame had its own scale and offset. This seems like an upgrade but when combined with interpolation it could also result in a pretty ugly "vertex swimming" (jiggling) effect when you tried to portray subtle movements, like the idle anims for the player's weapons.
One of the many things I admired from Quake is that there was a pretty uniform scale of detail to everything. There wasn't really anything that had higher polygon detail, texture resolution, or animation rate compared to anything else in the world. Everything looked very solid and consistent because of that. Quantized vertex coords was one of those tricks that seems restrictive but it didn't hurt them with the game they designed
Tools like Lisp are essential in your toolbox for whatever language you use for coding. If you can script and automate and test everything life is much better.
Most of the pain in software development is self inflicted. The most boring something is for a human, the easiest is for the computer to make it.
Lots of people coming from the "code must be efficient" front, like assembly, c and c++ programmers simply ignored the interpreted, functional and painfully slow "you don't know how things are implemented" world and viceversa.
But both worlds are complimentary.
When I was a kid I discovered Numega SoftIce. That was an incredible debugger and you could automate everything.
Turns out you can do the same with gdm and lldb today and bugs just pop up from automatic tests.
Man, so much fun was back then.
Story time. One of my clients wanted to reverse engineer a trading algorithm and the only option was the nuclear option. Fully disassemble and in-memory hunting this encrypted, split into different DLL's function that was holding the entire algorithm. Warned the client that would take as much as half a year and can possibly run up to more than $100k. He accepted saying if it's successful then it can gain him millions. So I started the hunt. A few weeks down the road, my client, while we were chatting the usual status and whatnot, dropped the bomb. This algorithm was actually old, as in WinXP era. And I asked "do you have a WinXP variant of this that you'd be satisfied with if I manage to reverse it?". And he said he has. I took that one, prepared a WinXP machine with SoftIce in it and job was done 3 days later.
The level of control you have with SoftIce, you can't achieve it with anything else.
According to the appendix (1), this content was posted to Blues News in 2000.
First article: Quake's Game Engine: The Big Picture - Dr. Dobbs Sourcebook, Sprint 1997, #279, pp. 58-60. Last article: Inside Quake: Visible-Surface Determination - Dr. Dobb's Sourcebook, Jan/Feb 1996, #255, pp. 41-45.
https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
And if you happen to be motivated enough, maybe you end up doing something like this,
https://www.raspberrypi.org/blog/pifox-bare-metal-arm-assemb...
A common solution is to make a low-resolution texture (like 800x480), draw onto it with a software renderer, then use hardware rendering to scale it up to full-screen. You can even add filtering like faux scanlines or a convex CRT effect.
Incidentally, I have an ongoing hobby project that does just that: a pure software platform-agnostic 3D renderer with zero non-optional dependencies written in Rust. It comes with a few example programs that use SDL2 and ncurses(!) to handle display and events. I'm planning to add a Wasm example at some point as well.
The project is heavily work-in-progress, and definitely not yet optimized nearly to Quake levels, but on the other hand the code should be relatively clean and useful for learning purposes.
It's another one involving Michael Abrash and it has inspired many research papers. For example, Intel developed a CPU rasterizer to handle occlusion culling and it can be faster than the GPU equivalent as it doesn't need retrieve data back from GPU to cull the draw calls: https://software.intel.com/content/www/us/en/develop/article...
Strange how much new area was quickly covered in such short time. Of course, the platform itself was developing to make this possible. One couldn't have done dynamic lighting 3d worlds with a 386 or multiplayer 3d shooters with 2400 bps modems.
There have been attempts to board new, moving platforms like VR but no breakthrough yet?