Graphics Programming Black Book by Michael Abrash (2001)
1–10 of 85 posts
Re: Graphics Programming Black Book by Michael Abrash (2001)
#2To save others the disappointment of expecting a 2019 update, this is a cleaned-up copy of the classic text.
Re: Graphics Programming Black Book by Michael Abrash (2001)
#3I read "Graphic Programming Black Block" and for a moment thought that the demoscene had an awesome revival!
Re: Graphics Programming Black Book by Michael Abrash (2001)
#4> Markdown source (2001)
This looked like a peculiar anachronism, as Markdown was created in 2004. But apparently this isn't the original source, but rather a scraped HTML[1] version converted to Markdown[2] in 2013.
1: https://github.com/jagregory/abrash-black-book/commit/b946ff...
2: https://github.com/jagregory/abrash-black-book/commit/5e1079...
Re: Graphics Programming Black Book by Michael Abrash (2001)
#5I still keep the original version. I bought this book with very little money in 2001. Back then not many book covered algorithms.
I can hardly remember from todays perspective how it was looking after some code snippets in books without google, github, stackoverflow, strg+f.
Re: Graphics Programming Black Book by Michael Abrash (2001)
#6> Markdown source (2001) This looked like a peculiar anachronism, as Markdown was created in 2004. But apparently this isn't the original source , but rather a scraped HTML[1] version converted to Markdown[2] in 2013. 1: https://github.com/jagregory/abrash-black-book/commit/b946ff... 2: https://github.com/jagregory/abrash-black-book/commit/5e1079...
Repo owner here. You are correct, not sure why this wasn’t made clearer by OP.
Book released 1997, made available online in 2001, converted to Markdown/ePub/etc by me in 2013.
Re: Graphics Programming Black Book by Michael Abrash (2001)
#7> Markdown source (2001) This looked like a peculiar anachronism, as Markdown was created in 2004. But apparently this isn't the original source , but rather a scraped HTML[1] version converted to Markdown[2] in 2013. 1: https://github.com/jagregory/abrash-black-book/commit/b946ff... 2: https://github.com/jagregory/abrash-black-book/commit/5e1079...
Repo owner here. You are correct, not sure why this wasn’t made clearer by OP. Book released 1997, made available online in 2001, converted to Markdown/ePub/etc by me in 2013.
Nice work. I don’t know if I’m ahead of the curve but iBooks on iPadOS beta 13.1 comes up with a resource error for the ePub; don’t try this at home kids.
I trust there’s a way to get iBooks log files to fix issues...
Re: Graphics Programming Black Book by Michael Abrash (2001)
#8Questions for experts: are part of this "timeless" and still relevant today, or is it mostly historical ? (Chapter titles like "Pushing the 286 and 386" are a bit scary :D)
Re: Graphics Programming Black Book by Michael Abrash (2001)
#9Questions for experts: are part of this "timeless" and still relevant today, or is it mostly historical ? (Chapter titles like "Pushing the 286 and 386" are a bit scary :D)
It's definitely mostly historical but it is an excellent read anyway if you're interested in what kind of problems faced game developers at the time and to what lengths they had to go to solve it. The chapters about getting Quake rendering to a decent level along with John Carmack are great. So, strongly recommended if you're interested in the technology during that era, not so much if you're expecting a lot of technical information that is directly applicable to current day game/graphics development.
Re: Graphics Programming Black Book by Michael Abrash (2001)
#10Questions for experts: are part of this "timeless" and still relevant today, or is it mostly historical ? (Chapter titles like "Pushing the 286 and 386" are a bit scary :D)
Some parts are timeless, like this introduction in the first chapter about optimization:
---
Understanding High Performance
Before we can create high-performance code, we must understand what high performance is. The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless.
Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler, or, for that matter, a compiler at all. It also doesn't say anything about how the code was designed and written. What it does say is that high-performance code shouldn't get in the user's way—and that's all.
That's an important distinction, because all too many programmers think that assembly language, or the right compiler, or a particular high-level language, or a certain design approach is the answer to creating high-performance code. They're not, any more than choosing a certain set of tools is the key to building a house. You do indeed need tools to build a house, but any of many sets of tools will do. You also need a blueprint, an understanding of everything that goes into a house, and the ability to use the tools.
Likewise, high-performance programming requires a clear understanding of the purpose of the software being built, an overall program design, algorithms for implementing particular tasks, an understanding of what the computer can do and of what all relevant software is doing—and solid programming skills, preferably using an optimizing compiler or assembly language. The optimization at the end is just the finishing touch, however.