Reddit reviews Michael Abrash's Graphics Programming Black Book (Special Edition)
We found 10 Reddit comments about Michael Abrash's Graphics Programming Black Book (Special Edition). Here are the top ones, ranked by their Reddit score.
Used Book in Good Condition
Graphics Programming Black Book
His book is a Bible.
https://www.amazon.com/Michael-Abrashs-Graphics-Programming-Special/dp/1576101746
It's hit and miss. A lot of it deals with outdated assembly language minutia, to the point where he actually reorders assembly by hand to handle pipeline stalls on the pentium. But there's a lot of good left in it.
Take the chapter on string searching, for example. He'll start out with the simplest string searching, and then introduce concepts like searching for less common characters first, and eventually lands on the boyer-moore algorithm. Even though the book is 90% assembly, he repeatedly makes the point that algorithmic changes gives you 100x speedups, while assembly rewrites only give you modest speedups.
However, if you're into game and graphics programming, I recommend going straight for Abrash's compilation book:
https://www.amazon.com/Michael-Abrashs-Graphics-Programming-Special/dp/1576101746
It contains pretty much everything he's ever written. The entirety of the Zen of Code Optimization, the Zen of Graphics Programming, and a whole bunch of stuff from when Abrash was developing Quake with John Carmack.
Most important thing IMO is /u/MysteryMo 's response cause if you don't like it, then you probably won't finish it.
Projects that got me into what appears to be high places in this field were things that are very painful to do due to the amount of things you need to know. For example, making your own game engine with a renderer is a very obnoxious task and you have to not only be good at linear algebra/math/physics/networks/etc, but your programming skills and debugging strategies cannot suck. Even then when you're passing stuff off to the GPU with OpenGL (or w/e library here), sometimes even then you have no idea why suddenly all your polygons aren't rendering and no output message as to why. There probably are tools to help with this but I could only find one and it was outdated. You will be probably reading a literal fuckton of articles, considering learning assembly to use SSE if you're not using a GPU to do all the good stuff for you, and also dealing with the aspies of the internet when you try to get help on some problem you run into. For example, to get a software renderer running, I had to read tons of textbooks in my free time and spent countless hours absorbing tomes like this just to understand the higher level concepts and play around with optimized implementations.
Maybe a combination of all the above is why some of these projects look really good, since they're generally a pain in the ass to do right even if you know what you're doing.
If the project does something epic like has distributed system components that serves people stuff, this will look a lot better than the next run-of-the-mill-CRUD-app.
I sometimes wonder if maybe taking some cutting edge algorithm and coding it or implementing some advancements with it would be less painful than the journey I took, and also look better.
I still have my Black Art of 3D Game Programming around here someplace ...
I always thought he was over rated compared to Michael Abrash's Michael Abrash's Graphics Programming Black Book
Senior Level Software Engineer Reading List
Read This First
Fundamentals
Development Theory
Philosophy of Programming
Mentality
Software Engineering Skill Sets
Design
History
Specialist Skills
DevOps Reading List
You didn't post a question, so it's difficult to know what exactly you want. If you just need to implement space partitioning with a BSP tree, read the good old BSP FAQ
If you need more general graphics background, check out:
If you have more questions, please be more specific. I might help you with more resources.
Also read up on Abrash's book.
http://www.amazon.com/books/dp/1576101746
The last couple chapters goes into when Abrash was with iD and was there with Carmack when he was coming up with the following: " Optimized solutions to 3-D graphics problems from texture mapping, hidden surface removal, and Binary Space Partitioning (BSP) trees are explained."
I was more surprised by Michael Abrash, the guy is a genius when it comes to assembly and was essential to the development of Quake, even AutoCAD's line drawing algorithm from when there was no hardware acceleration is his creation. That book is worth reading even with the assembly part being outdated, merely because of the historical side and the creativity he shows to optimize solving problems.
You are correct that it isn't really 3d, it is lots of 2d shapes rendered to look like 3d.
The DOOM Engine did something unique though which made it so much faster than the other games. In other games, the rendering process would be like you said; start from things farthest away and rendering until you get close to the player. Abrash and Caramack implemented Binary Space Partition (BSP) tree creation that was used to quickly figure out which part of the maps did not even have to be considered to render.
This is a great link showing how the BSP was referenced all the time during gameplay and how the calculations worked.
http://fabiensanglard.net/doomIphone/doomClassicRenderer.php
I think you also might be interested in buying my fav book, Michael Abrash's Graphics Programming Black Book. It has a lot of discussion on 3d engines including how the DOOM/QUAKE engines were built and their weaknesses but also includes anecdotes during their development. Quake still used BSPs, but built a whole new process (QVIS) where the compiling calculated exactly what surfaces a player could see from any position in the map and know which surfaces to load because they might see it soon (like rounding a corner).
https://www.amazon.com/Michael-Abrashs-Graphics-Programming-Special/dp/1576101746