Some interesting related stuff in this talk: HandmadeCon 2016 - History of Software Texture Mapping in Games [this video] I think they say at one point it went from 14 to 8 instructions, and then the Duke Nukem guy (Ken Silverman) got it down to around 4. Quake would do something where it only issued a divide every 8 pixels or something, and then only interpolate when inbetween and the out of order execution on pentium pro (I think?) would let it all work out.
Veterans discuss software texture mapping optimizations in 90s games.
From the horses mouths (minus Abrash/Carmack) 'HandmadeCon 2016 - History of Software Texture Mapping in Games' [this video] Wolfenstein and Doom are 100% correct because Carmack 'cheated' by deciding to never look down/up or draw slopes :-) so whole game is drawn with 'lines of constant Z'. Or as they put it Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math
Pioneers explain how Doom and Wolfenstein avoided heavy math.
I guess Michael Abrash's Graphics Programming Black Book fits the bill, though no amount of literature replaces getting your hands dirty in late 80s-early 90s level hardware+software. However, while you can do this, you're still missing the things you learned by being part of a team (of the kind which there are probably in the low hundreds right now). How much I'd give to be part of Nintendo or Id software or some other era-appropriate team figuring out how to make the early big 3D games like Mario 64 or its contemporaries on the PSX. Of course you can bust out an SDK and try it out but it probably won't be the same. Those teams built up that kind of tacit knowledge like in this video about software texture mapping [this video]
Example of teams accumulating tacit knowledge about texture mapping.
- it didnt, at least not Intel x86 MHz - doom doesnt operate on pixels, it operates on constant-z planes (lines), you can scale linearly inside those (cheap 2D operation). How Carmack did it? He cheated by deciding to never look down/up or draw slopes :) 'HandmadeCon 2016 - History of Software Texture Mapping in Games' [this video] Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math
Source for how Doom rendered with constant-z planes.
Garret’s buddies at HandmadeCon gathered a group of devs from different games who all wrote some of the first software rasterization 3D games. The general theme was “We had no idea what we were doing. There were no references!” [this video]
Devs of early software 3D games recall working without references.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
5 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more
Read more