Thanks for the kind words, everyone - this brings back a lot of memories for me too. You know, I wrote everything in that book either late at night or on weekends, and I never really knew if it much mattered to anyone (feedback was a lot harder to come by in pre-Internet days); reading these comments goes a long way to making all that work worthwhile.
Oh, and laichzeit0 - my apologies to your dad for the weight of the book. There have been a few times when I was lugging one around and wishing I had been more sparing with the words :)
It will never be outdated thanks to all the happy memories it holds for me. Thanks for writing it, Michael. It's one of a few books I will never part with.
Ah man this brings back memories. I have the book + cdrom sitting here on my bookshelf. I was 14 and just started learning to program with Turbo Pascal and assembler by reading Denthor's Tutorials on how to program Demos. My dad happened to be going on a business trip to the U.S. (we didn't have nice books like that in South Africa) and when he asked what I wanted I said "the Graphics Programming Black Book" not knowing how big and heavy that thing was and he had to lug it around with him.
At the time I didn't understand much of it but I remember the evolution of him optimizing Boyer Moore string search left quite an impact. That and the anecdotes of him working with John Carmack at the time they were coding Quake I. Just browsing through the chapters makes me want to read the whole thing again.
I remember the Denthor tutorials! Downloaded from a BBS, learned the basics of graphics programming... Mode 13h... :) I emailed Denthor once and thanked him (shortly after I got my first job in '96).... I have the Black Book as well, good memories!
I implemented Bresenham's algorithm in ARM assembly on the gameboy advance based on reading his 'zen of graphics programming'. Great writer, the anecdotes at the beginning of each chapter really hooked me in.
Jack was my graphics professor. After taking his class, I realized that I was never going to be a guru in the subject. :( But I did learn that a v1.1 of a C compiler (Borland Turbo C) produced much slower code than the highly optimized Turbo Pascal, then at v4.0
Michael wrote an article about quake once that described the inner loop optimization of the software renderer. I recall he was computing a dot product or something that was used over an 8 pixel span. The hack was that he started an fpu divide and then got useful work done on the integer pipeline without a stall, perfectly timing out when the fpu would have his value ready. What a brilliant hack. I recall the satisfaction of knowing so much secret knowledge. :)
This was referenced in a HN article that I read in the past day. I checked out reviews and it seems like it's a bit dated. Many chapters are done in assembler, for example. Any recommendations on great books that cover OpenGL and game programming?
Instead of spending $$$, you should work through Learning Modern 3D Graphics Programming [1]--it's a great resource and should get you started on your way to building something more complex.
Not just a little dated, a lot of the examples are targeting 8086, 286, 386 or 486 CPUs, and EGA or Standard-VGA graphics cards (you know, those with 0.2MB ram) running on 16-bit MS-DOS. :)
Back then this was a goldmine of tricks.
But I'm sure the algorithm parts are still relevant.
Yes, it's still worth a read, the assembly parts have become somewhat historic but it's a nice explanation of the "way of thinking" that's still valid today if you need to optimise in assembly (of course, targeting it for the modern archs).
Apart from that it's a nice read and some of the outdated parts might be skipped.
He actually made the point right in the book that the code was obsolete from a use perspective. The relevance (even today) was in understanding how the computer works so you could make tradeoffs. I still remember the video 7 story at the beginning of one of the chapters.
While I agree it's dated in lot of ways but it is still a great read. I am not a game dev but I love to write performant code, it's just a personal satisfaction when I know my code is making the best use of the hardware.
I think you should read the first chapter at least, on how he approaches code optimization, first by design and then by code.
This book teaches you to think like a performance programmer like no other. In the first chapter he challenges assumptions, for example how lib C code is not really optimally written (its written for portability and general purposes) and you can easily write more efficient algorithm to do the same.
The mindset of not being at mercy of the library is a powerful one, it inspires you to dig deeper and find out how things really work. Thus, you make the best choices for the problem in hand.
Yep, I'm sure there are still great nuggets in the book. Unfortunately it looks like I'm not going to get my question answered about modern OpenGL books because everyone just jumps in and says that you should still read Abrash's book.
John Carmack, for example, didn't write much of his games in assembler because he knew that he didn't have to. If you look at Doom, there wasn't a lot of assembler even back in the early 1990's.
"With OpenGL, you can get something working with simple, straightforward code, then if it is warranted, you can convert to display lists or vertex arrays for max performance (although the difference usually isn't that large). This is the right way of doing things -- like converting your crucial functions to assembly language after doing all your development in C."
I actually have done some basic assembler so I do understatnd the benefits of keeping values in registers, etc. A lot of stuff really is architecture dependent, of course. ARM vs x86 will make a difference.
Anyway, where's the best place to start these days? Personally, I'd like to do some iOS stuff, and perhaps keep the same code running on Android.
This isn't what you asked, but as a professional mobile game dev I can tell you that even c++ & opengl is too low level for what you need for most mobile games today, on android and ios.
There are a lot of options such as unity, haxe/openfl, adobe air, etc. Most of these are very easy to pick up by just reading one of the many online tutorials.
Red book is following the current version. I believe they had 3.x edition for a while. Anyways, why you'd care about 3.x if you are targeting iPhone/Android?
Well, iOS 7 does support OpenGL 3.0 ES. If I'm starting now, why wouldn't I want to target it? By the time, I'm done with my first app, iOS 7 will be on over 80% of the iOS devices.
I checked and Android 4.3 supports 3.0. KitKat's low memory support should mean that even new cheaper phones will get Android 4.4 in the near future.
OpenGL 3.0 and OpengGL ES 3.0 are different APIs, with later based on a subset of OpenGL 2.x as same as OpenGL ES 2.0.
OpenGL 3.x seems like a dead end IMHO. I only follow the Kronos group antics as a spectator, so I might be completely wrong but it seems the 4.x is trying to clean the mess of 3.0 and not building over it. It could also be the reason the 3.x redbook did not get enough Amazon stars for your satisfaction.
These days most devs would enjoy Abrash's awesome story telling ability over the intricacies of long forgotten x86 chip instructions for software rasterizers.
Oh, and laichzeit0 - my apologies to your dad for the weight of the book. There have been a few times when I was lugging one around and wishing I had been more sparing with the words :)
--Michael