Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Michael Abrash's Black Book For Download 91

Decado writes "I found out from gamasutra that Michael Abrash and Dr.Dobbs Journal have made Abrash's now out of print "Graphics Programming Black Book" available for free download here. Written at about the time he was finished on Quake it was one of the most readable and informative books on graphics programming. Abrash begins each chapter with a real life anecdote to the problem he is solving and you can't help but think he is a cool guy. Though fairly dated now it is still a great read and his approach to optimisation still holds true today."
This discussion has been archived. No new comments can be posted.

Michael Abrash's Black Book For Download

Comments Filter:
  • by Anonymous Coward
    I've had this one for a while in paperback, and although a lot of it is hopelessly outdated (c'mon - optimizing for vga???), it makes a great read, especially some of the later chapters. The explanations of the bsp scheme that Quake uses (the original, but almost all of this still applies up to and including Q3) is priceless, and a better presentation of the material than most other books I've read. His working on X-Box is one of the few saving graces I can think of for the console. Well, that and what I'm sure what'll be a gazillion dollar marketing budget. BTW, if I'm not mistaken, his "Zen of Assembly" books have been out there in text format for a while now, if you can find them still.
  • by Anonymous Coward
    Since the specific optimizations are out-of-date, here's a summary of the timeless elements of the book:

    OPTIMIZATION IS AN EMPIRICAL SCIENCE
    MICHAEL ABRASH IS A "COOL" GUY

    That should save Dr Dobbs a few gigs of bandwidth.

  • by Anonymous Coward
    You try writing a PS2 game without using assembler! Or a cool GeForce3 effect without writing vertex shader code. Assembler is becoming more relevant, not less.
  • by Anonymous Coward
    A compiler can`t create better code than a good programmer(not at this point) so there
    is always room for assembly in critical loop areas where the time saved is exponential.

    Although unless your still writing code for an 8088, 8086, 386, 486 or a Pentium most of the optimization techniques like pairing instructions in the U and V pipes don`t apply to the Pentium pro +, but this book still has plenty of valuable info that applies to programming today and does contain C code as well.

    This book is a classic and still worth the read, it also would be my book of choice if
    I needed to defend myself in a life-threatening situation(it`s 1342 pages).
  • by Anonymous Coward
    Have an unpublishable book?

    Unsure about the actual size of your potential audience?

    Want to know how many pack rats live on the Internet?

    Well, we have the answer to all your really obscure publishing questions.

    Don't bother with finicky publishers who are
    unwilling to take risks with unproven material.

    Our simple strategy will give you *real* numbers
    that you can take above the editorial/scout level,
    giving you the power to negotiate your own deal:

    (If I were for real, I'd ask you to buy my 30
    miniute audio tape (cheaper than paper) for 19.95
    with your visa *right NOW, damned it!*... but I'm
    a nice guy so I'll let you in on the obvious:

    ...simply put up a web site that is capapble of
    tracking the hits but not delivering the actual
    content; hide behind "copyright" laws, summerize
    the log file hit count with pretty, colorfull
    bar charts, advertize the "resource" to as many
    "Open Source" venues as humanly possible and sit
    back to wait for the numbers to roll as you're
    ./'ed by the Internet at large.
  • by Anonymous Coward
    Do you remember the Illegal prime a couple days ago? It was submitted by Phil Carmody (the person who found the prime in the first place) days before it appeared on slashdot and was rejected.
  • No troll... just a poorly worded plea for improved graphical design. And not just eye candy... but good design.
  • Well, if enough people are interested, I'll put my UID for auction on eBay. I'm no expert. I'm not even smart - just been readin slashdot for a hecka long time. Ahhh... the good old days of bits and bytes.
  • Definately worth a good read, along with his 'Zen of Code Optimization'.

    Hm, I have to have a look at my copy of the Black Book, I think he put the "Zen" on the Black Book's CD-ROM.

    In that case, the online version would be less rich regarding information than the print copy. :-)

  • Hardware performance does not, and cannot, increase as fast as we'd like it to. We always want to do more ... and therefore, optimization is one of the tools to use to be ABLE to do more with what we've got.

    Nobody sane is advising the writing of whole programs in assembly language -- rather, the writing in assembly of small, frequently used routines whose absolute efficiency is important.

  • I bought this book a few years back. The CD that came with it had a couple other texts included with it. Zen of Assembly Lang was one I think. Its a great book all the same. All you wanted to know about VGA registers... :) I think its worth the $59.99 cover price :) Leimy
  • Such an great resource being shared. After learning how to do network programming this will be my next endeavor
  • by GypC ( 7592 )

    Oh, and that damn pdf reader for unix keeps crashing on my solaris box. pppffft.

    Which one? Try gv... it antialiases the fonts and has never crashed for me.

  • Yeah, it's the New Jersey method ("Worse is Better")... make something with a decent base design, nice and simple, get it working 90% and release it, hoping that the remaining bugs will get fixed sometime later. Remarkably, this method, however flawed, has proven to be quite adequate for a majority of the world's computing needs so far, as attested to by the enormous popularity of Unix and Microsoft systems. "Working tools now are better than perfect tools later." Unix pulls it off with an unexpected grace, due in a large part to the fact that its programs are usually small and relatively easy to debug and have had many years to mature, and some big design wins in the flexibility of the system ("everything is a file", "plain text is a universal interface").

    Actually, the Redmond method is a bit different ("Good enough is Best"), copy something, anything that looks good and can check off a buzzword list of features, get it done good enough to compile and run a little then ship it off to your world class marketing department to grab market share as soon as possible. Fix bugs later if the customers actually need a better program as a reason to switch from your competitor's (they rarely need a good reason though).

  • The attitude is not sloppy, the attitude is precise. There are three discrete stages that should be taken when writing a piece of code. First, make it work. I cannot stress this enough. Far too many people spend far too much time optimizing broken code. Once it works, make it robust. Then, once both of those are finished, make it fast. I'd be really surprised if you can write decent code while covering those three issues all at the same time, and more surprised yet if you can keep it up for anything more complicated than the latest Pong clone.
  • I'd suggest you first see how high-level concepts are handled. Try papers from the UW Cecil/Vortex project:
    http://www.cs.washington.edu/research/projects/cec il/www/Papers/papers.html [washington.edu]
    And maybe start from:
    http://www.cs.washington.edu/research/projects/cec il/www/Papers/whole-program.html [washington.edu]
  • by kallisti ( 20737 ) <rmidthun@yahoo.com> on Friday March 23, 2001 @03:11PM (#344010) Homepage
    If the "Black Book" being released is the same as the dead-tree edition I am checking right now, it includes the Zen of Code Optimization. In fact, it is a collection of Zen of Code Optimization, Zen of Graphics Programming, all the Dr. Dobbs and other magazine columns, and some extra Quake-related articles. 1342 pages full of hardcore goodness.
  • Why are optimizing compilers bad? You can still optimize the slow stuff by hand, and you can get the (mythical) 2x performance boost over the rest of your code too. And how did you find out where that 99% of your run-time was spent? In the profiler.

    My point was that there is a much bigger win from prifiling your program and reengineering the hot spots (perhaps by assembly, but better algorithms and data structures in the general case).

    The only time you should have to resort to assembly is when you have absolutely performance critical tasks, ie Interrupt Service Routines.
  • More importantly, if you don't do serious work in assembler sometimes, you won't understand the machine.

    I agree. Everyone needs to write a non-trivial program in assembly for at least one computer. That single project will give you in intimate understanding of the underlying architecture on modern computers, and make all of your work better.

    It's best, however, if that project does not escape into the real world, because your assembly hack is not a good program. You'll not use complex data structures or advanced object oriented design in assembly - there's too many nit-picky details for mere mortals.

    The tools of the modern C++, Java, programming languages allow a fully thought-out, engineered software design. The tools of the assembler allow near optimal implementations of hige-traffic areas. A good mix of these tools can provide fast, robust, and maintainable projects.
  • by tonyj ( 20863 ) on Friday March 23, 2001 @12:48PM (#344013) Homepage
    There's two ways to look at this. A good programmer shouldn't need to resort to assembly in nearly all cases since a good algorithm and software design will do the trick. Hand-optimized assembly is difficult to maintain.

    Learning to spot optimizable spots in assembly is probably not a good application of time, since a profiler will happily tell you where in your code you should consider optimizing.
  • I picked this up at the local Borders recently from the big piles of out-of-print stuff up at the front of the store. I think I paid around 5 bucks for it, and it included the "zen" title on CD. I can't imagine wanting to DL this to read. This baby is a fairly thick book. Hopefully there are still more available at other Borders for other people.
  • There's a similar algorithm by Wu (IIRC) for drawing anti-aliased lines. You figure out how far you are from the 'true' line and use that as a ratio between source and target colors for your pixel and ( 1 - that ) for the source and target colors of the next pixel up. Once you get further than 1/2 pixel from the line offset by a pixel and start over.

    There's a similar one for circles. I implemented them both for Windows and they are sweet and elegant. The Wu paper is on SIGGRAPH, but you need to pay for it. I found a short summary on an ftp site somewhere. E-mail me if you are interested and I can dig up the doc (it's a little too long to post here).

    Rick

  • by fizban ( 58094 )
    ...now it's good enough for you. How come it wasn't good enough 3 days ago when I submitted it? ;-b

    2001-03-20 17:00:47 Graphics Programming Black Book now online at Dr. Dobb's Journal (articles,programming) (rejected)

    Who takes the bribes here? Give me some names...

    Seriously, though, Abrash is a god, and if you are at all interested in programming fast and furious graphics applications, he is definitely one of the best reads out there. There's just so much good solid foundation knowledge you can gain from his books that will help you not only create better graphics and games programs, but also better apps in general. Just going through some of the problem solving steps that he takes when discussing his stuff can make you into a smarter developer. Go get your coffee, curl up with a good computer in front of the fireplace and start reading this fantastic piece of work.

    --

  • The clever bit is finding ways to keep track of the error without using division.

    The algorithm can be easily obtained by writing the obvious iterative algorithm in floating point, then separating the fractional part from the integer part, and finally multiplying the fractional part by the length of the longer dimension (times 2 if you're using midpoint-Bresenham) to turn it into an integer.

  • For larger projects where there's maybe 6 megs of code, intimately understanding what's going on everywhere is a lot less appealing. Especially if there are 3 or more people working on the project at the same time.
  • Actually, this was covered in a book I read (Wu's algorithm), and I'm 90% sure that book was written by good ole Michael Abrash. I even remember where I was sitting while I read that chapter.

    -Puk

    p.s. It wasn't a chair. ;)
  • by Majestik ( 101669 ) on Friday March 23, 2001 @12:16PM (#344020)
    I remember reading Mike's book years ago (as well as the weekly DDJ columns) and it provides an excellent amount of fundamental graphics and optimization information.

    If you ignore the fact the some of the information is dated you'll find that this provides and excellent approach to optimization (which can be used in various design environments) and great anecdotes, much in the same way that The Mythical Man Month [slashdot.org] does.

  • I bought his book like 4 years ago and it was pretty much dated then (assembly was definitly already on its way out). Still a very interesting read. Optimizations from the master
  • DDJ is dead (fopr the moment). could someone who got in early put up a mirror. Thanks JFMiller
  • I don't recall where I saw this but it makes sense: don't use the "*-line" down the left side of the comment, just the "/*" and "*/" parts on lines by themselves. Makes editing easier, perhaps at the price of some visual distinction.

    (vaguely related: damn I wish somebody would "back port" the "//" comment notation from C++ to C. So much quicker to type for those quick one-liners to explain a small point...)


    --
    News for geeks in Austin: www.geekaustin.org [geekaustin.org]
  • You're right! :-) It was really bugging me where that came from... But now I recall reading it there. Thanks for reminding me, otherwise it would have bugged me for days...


    --
    News for geeks in Austin: www.geekaustin.org [geekaustin.org]
  • Comment removed based on user account deletion
  • 2001-03-22 00:13:29 Abrash's Graphics Programming Black Book Free! (articles,programming) (rejected)

    Why God why?
    --
    Peace,
    Lord Omlette
    ICQ# 77863057
  • look at my date and look at the date this guy got the story posted? slightly unfair... is flooding the submission queue the only way to get noticed?
    --
    Peace,
    Lord Omlette
    ICQ# 77863057
  • thanks, I appreciate it :)
    --
    Peace,
    Lord Omlette
    ICQ# 77863057
  • hehe. damn this is a classic Book-A-Minute [rinkworks.com] type review. Too bad they don't have a computing section. Thanks.

  • Not to mention that it makes it A LOT easier to comment out a few lines of code - you surrond the lines to comment out with /* and */, and it works EVEN if there are comments (of the // type) inside the block. This is a thing that really makes me hate people who use /* */ as comment inside the code.

    In languages with conditional preprocessing (such as C, assembly, and C++ but alas not Java), you're not supposed to comment out large blocks of code (more than about 2 lines); instead, condition them out with

    #if 0
    ...
    #endif
  • vaguely related: damn I wish somebody would "back port" the "//" comment notation from C++ to C

    It's already happened. It's in GNU C (the language that gcc compiles) and in C99 (for which there is no compiler, but gcc comes closest).

    Here's another tip: Turn word wrap on in your editor and never have to deal with hardwrapping comments again. Just a /* (paragraphs of comments) */ with no hard returns except between paragraphs.

  • 13 minutes after posted and already slashdotted
  • I meant painfully slow, plus there's no link so you cannot easily find what you want, the quality of the fonts is plateform dependent (like HTML) but I don't care about that. Plus the files are way bigger. It's good for printing but reading on a desktop is not enjoyable for me.
    --
  • Oh boy, the PDF vs. HTML war. When it comes to reading things on screen, I'm firmly in the HTML camp. The PDF viewer is unstable on my box, it always defaults to page flipping mode, and antialiased fonts are ugly unless you blow them up. Then you have to scroll sideways. Yuck.

    That said, it's perfectly understandable why this is PDF. It was a book, remember? For work that is destined for the offset press, PDF, PostScript, or something else that forces an exact size is ideal. For work that is destined for the screen, HTML is better. What's needed is a free tool to convert PDF to HTML that is a decent approximation of the PDF.

    I've seen documentation that was originally TeX and was converted to HTML, and it looked pretty decent. I haven't actually viewed TeX documents, but if it is a page layout like PDF, and *it* can accomplish this, I see no reason why PDF can't.

  • Sounds like a great idea. Having older references available makes "legacy" systems that much easier to deal with. (I wouldn't consider oracle 8 a legacy system yet, we just upgraded from 7 about a month ago ;)
  • by StarDrifter ( 144026 ) on Friday March 23, 2001 @01:49PM (#344036)
    A portion of the book (the DDJ articles relating to Quake) was already available online:

    http://www.bluesnews.com/abrash/ [bluesnews.com]

  • Just on Tuesday, I discover that my friend Laura is his boss (well, officially, anyways... some people don't really have a "boss" as such, y'know?), and now this. Wierd... So far as the book goes, yeah, download it sometime when they're not so overloaded, and go read the thing. It's good stuff, maybe not as frequently useful as something like Fowler's Refactoring, but still good.
  • actually yes. My last gf was a model and the one before that could have been. My only problem is shyness - the girls I've gone out with have asked me out, not the other way around.

    Whats eerie, though, is the number of gay men that have hit on me. Yikes. I don't know why that happens, I'm not interested in the least.

  • I've wanted to see this for a while. My current hobby projects consist of learning assembly, learning how to make a compiler, and trying to get a good understanding of what happens behind the scenes when using a higher level language.

    I would love to be one of those guys who can eyeball compiler-generated assembly and quickly identify parts that can be optimized. Since I can still easily bring the fastest machine to its knees in terms of processing I think optimizing techniques and assembly are far from obsolete.

  • ... about computer things... does that make me cool too? Like this guy who wrote this book?

    Actually, this sort of thing is what we need more of in computer documentation. Compare the fluid vast documentation of say, PHP [php.net], to the rigid cold nothing that is MySQL [mysql.com]. Stories, fables, whatever... it worked in the past to convey complex ideas, and we must as a whole develop man pages for masses.

    HotelNIX [sourceforge.net] is my idea to have stories contributed from the public that convey complex computer programming or administrative tasks in clear, easy to relate stories. I need help with developing a submission/content management system. Anyone interested?

    ----

  • bleh, who knows. it happens sometimes.

    I thought GarageGames' announcement that you can get the sourcecode for the Tribes 2 engine for just $100 was pretty newsworthy, but the editors obviously didn't.

    /me shrugs
  • I have been after a copy of this book since last Spring (amazon, bibliofind, ebay: always I was thwarted!!)... thank goodness this is being done... perhaps tomorrow I will be able to download this, as it seems the entire world is doing so right now... this may be the finest /. item ever. May it rise to the heights of the hof.

  • Mirrors sites are available as of April 5th from the original link.
  • This is offtopic, but I can't help myself.

    I've submitted three stories to slashdot that were rejected, only to be posted days later, after someone else also re-submitted it.

    This pisses me off more than it should. The slashdot editors have to sort through a lot of crap submissions, so I understand why they might be quick to dismiss. But it still feels like an insult to me anyway.

    The slashdot FAQ answers that they don't want to add a "reason" column because that might cost them a lot of time (sure, it's just a little time each submission, but there are a lot). On the other hand, I think that the slashdot editors are ignoring the harm they are doing to their own community--I'll certainly be less likely to submit that cool story next time, since it's probably just going to be quickly dismissed. In an ideal world, they would have a reason for rejection, and perhaps even a name. (They would also automatically run ispell on all stories, as well as have peer review by another editor who cross-checks against old stories, but that's another topic.) This would take more time, but there are legions of layed-off dot-com employees begging to be hired to do just this sort of thing.

    Just my two cents. At least know that you're not alone thinking that story rejection and posting is capricious and inconsistent.

  • You can find the Midpoint algorithm, a fast variant of Bresenham's algorithm here [freeserve.co.uk].
    --
    "Chiswick! Fresh horses!"
  • I fall firmly into the "debuggers are a seductive waste of time" category. The effort of guessing what is wrong is good training that gives you more awareness and control of your programs.

    I consider myself very good at understanding what's going on in the computer and then using that model to extrapolate back to what part of my code is buggy. I'll agree that the in-depth step-by-step debugging is a seductive time suck, but using the debugger to get a stack trace on where a non-trivial program core dumped has been insanely useful to me. That single bit of information, which requires almost no effort to produce (and only slightly more effort if we increase the likelyhood of it pointing at the true culprit by compiling with ElectricFence or a similar utility), is usually enough to make my mental model churn out a solution to the problem.

  • Hu? How is reading PDF painfull? Does reading smooth anti aliased fonts hurt your eyes? Admitedly I havn't downloaded this file yet so maybe it has oddities that make it hard to read in PDF. However PDF is a great way to distribute documentation. Unlike HTML it is a standard standard. That is every PDF viewer read every PDF like every other PDF viewer. The same cannot be said about HTML. Just try reading a the same html formatted documentation in IE vs Netscape 4 vs Netscape 3 vs konkeror vs ...well you get the idea.
    PDF is a god-send of a documentation file format. Its cross platform (cpu/os), cross viewer (xpdf, acrobat 3, acrobat 4, etc), has scaleable fonts, anti aliasing, never has print problems, and EASY to make for even the most assinine of computer users.

    There is only ONE dissadvantage of PDF's, and that is you need to edit the source document and re-distill to change them.

    Keep HTML in web pages, I'll keep my PDFs for documentation, thank you very much :)
  • by azephrahel ( 193559 ) on Friday March 23, 2001 @12:36PM (#344048)
    This really is the best graphics book I have looked through. I borrowed it from a former game programmer at work. Of course I still cant get him to lend me his "Graphic Gems" books. Apparently those are even MORE coveted. Still The Black Book should be on every game and graphics programmers bookshelf at all times! Personally I found this most useful when looking at it side by side with the Athalon optimization docs from AMD.

    Now if only more of these great books would make their way to a free online format. Sure there are many great works of fiction to be downloaded from Project Gutenburg, but the number of actually reference books in the online domain is pitifully small. (Note I said BOOKS, not very long documentation.)
  • I've had the black book for many years now, and have used it as a true bible for low-level graphics programming; it is a rare gem (albeit a heavy one). However most everything in that book is somewhat obsoleted now by the advent of hardware accelerated 3D and the divergence away from assembler coding.

    Back in 1994 it was still popular to write major parts of your game in pure assembler, relying on a high-level language to glue the asm routines together and set up the game flow. These days people just rely on the compiler to write 'optimized' code, and it does a pretty good job too, but no compiler will dare use extreme tweaking measures such as those detailed in Abrash's Zen of Assembler, such as unrolled loops, memory/cache latency timing, even clock counting. That's why you could run a decent action game at 30fps on a 486-dx2 or dx4, but when Win95 games started pouring out the wastepipe you found yourself playing cheap side-scrollers a-la-Mario at about 5 fps in a small window on your screen. "Who needs speed, we've got Win95!"

    Indeed, few of those who could tweak asm knew a thing about this mystical OS, so they just gave up. Those who persisted went on to start projects like Visual Assembler, but without coordination and support, they just fell through.

    It has simply become too cumbersome to write good code because the advent of more intricate OS' and exotic (read : OEM crap) hardware have made software development a mess. We have no choice but to rely on commercial libraries like DirectX to get anywhere. Don't even think of writing your own low-latency SoundBlaster driver, you'll miss out on half of your potential customer base that own lame stuff like onboard "almost SB compatible" chipsets or Yamaha 10$ sound cards. Drivers make all the difference these days, especially with video cards.

    Let's face it: Games no longer use or need good coders, all they care about are artists and designers. Having a good designer is primo, but artists ? Games don't need to look good if they play good. Just look at Alpha Centauri from our fellow brainiac Sid Meier. So-so graphics but great gameplay turned it into a guaranteed hit, because we don't want to watch the game, we want to play it.

    Abrash's insight still gives important lessons on good software design, not only graphics. It remains a true bible to those who dare walk through its pages and lift off the tender morsels of genius it contains.
  • Everybody who does any sort of design needs to go to that link, and read the first 4 paragraphs of chapter 1. It's amazing.
  • -- is an excellent author, and programmer. Even though I own it (and some of his other works) I sure hope they release 'Zen of Code Optimization' out to the public. A *very* nice book that covers the basics of code optimization that you'd be surprised most developers don't know or aren't thinking of while they code. Filled with more funny story lead-ins for each chapter as well, and a lot of personal information that kind of increases the interest overall in the topic at hand.

    If you've never read this book, or his Zen of Code Optimization book, I definately suggest trying to pick it up from a library or (I'm sure it's out of print, but worth a shot) book store.

  • Cool, I never checked out the Black Book edition because I figured it was just a re-release of his Zen of Graphics Optimization; if it really has Zen of Code Optimization as well then it'll be a real treat for developers/students since that was really the best text demonstrating how effective careful and sensible code optimization really was.

    I've got both books seperately though, the only one I didn't have was Zen of Assembly Language, a book that was later included in electronic format on one of his books CD-ROM's anyways..

  • No one uses assembly anymore to draw the the fancy triangles on the screen and this book is full of examples like this.

    I disagree, there are plenty of things that can be improved through assembly language, and through careful optimization of code. Especially with new instruction set enhancements such as MMX, 3DNow!, SSE and SSE2. Lest anyone reading here forget, Michael Abrash, already an accomplished developer, worked with id Software when they were working on the original DOS-based Quake. He talked about more than just graphics optimization, he talked about actually making the code DO less by arranging data intelligently. (Clearly something that can benefit developers to this day-- things like not rendering non-visible polygons are ideas that I got from Abrash's written works, and he has a whole treasure trove of good tips and ideas that can still be applied to todays work.)

    Definately worth a good read, along with his 'Zen of Code Optimization'.

  • Anyone know of any mirrors that do exist? I can't even get to the site....
  • This is a very interesting (and huge) book.
    About 3 inches thick in the dead tree version.

    I know this because it has sat on my creaking shelf since I bought it a couple of years ago.

    A bit like setting off on a long journey, it isn't got the faint hearted. Excellent read though with some great points on code optimisation and efficiency.

    After reading those bits, the Visual Basic project I was working on at the time looked as bloated and ungainly as Jabba, which, indeed, it was.

  • Google indexes PDF's. Another reason Google is so cool.
  • Ditto. Look around -- maybe you'll find a copy. Borders' "dollar bin" stuff sometimes repeats periodically.
  • actice. Way more readable, and way more game oriented. The dated info is regarding VGA registers, 8086 optimizations, stuff like that. And even then, it's a good illustration of how far you have to go beyond the manual to get the best performance. The graphics stuff holds up better over time.

    I was leaving the Barnes and Noble computer book section about a two years ago, and the author's name on the book stopped me. It was hidden in the graphics section next to Photoshop and Shockwave books, so a very lucky find for me!

  • So how does it feel working for the evil empire? Michael, there is more to life that you think, there is a free world out here. Get out of your cubicle in Redmond and be somebody again, make a difference. Instead of being a minion. Let's see you apply your considerable talent to doing something that will be remembered in a more favorable light than just helping billg buy his way into another market.
    --
  • Actually, I've been trying to download it for the past 3 days. It's been "slashdotted" ever since it went up three days ago. I've only managed to get chapters 1-9. I can't imagine that slashdot reporting this will help the situation any.
    ---
  • NO, i don't think it's a Troll.

    Well, i should not respond, but i can't control myself.

    Ricky

  • Most people convert TeX into PostScript file.

    Ricky

  • Is it a troll?

    I think not. So my opinion...

    These 'toys' are for professional programmers writing professional code.

    It's less useful when writing software for one platform only. If you want your code to be cross-platform (or at least multi-unix), then you should rely on optimizing compiler to do the dirty work.

    Just my 0.02 cents.

    Ricky

  • Unlikely he'd write an OpenGL book, at least in terms of how it related to game programming...He currently works for Microsoft, on XBox/DirectX.

    A hands-on Direct3D book from someone directly responsible for turning D3D into something great from the shitheap that was D3D 3 would be cool though.

  • by mrparker ( 265848 ) on Friday March 23, 2001 @12:17PM (#344065) Homepage
    Though assembly is not essential to graphics programming nowdays, a whole lot about optimization can be learned from studying assembly.

    Plus, if you ever plan on developing one of those new and exciting technologies it is probably best to learn how to write optimized assembly.

  • copy this into a text file
    run wget -i textfile_where_url_were_copied -t 0 -c -w 90 -t 90

    http://66.35.216.85/gpbb.pdf
    http://66.35.216.85/gpbb0.pdf
    http://66.35.216.85/gpbbintr.pdf
    http://66.35.216.85/gpbbpt1.pdf
    http://66.35.216.85/gpbbpt2.pdf
    http://66.35.216.85/gpbb1.pdf
    http://66.35.216.85/gpbb2.pdf
    http://66.35.216.85/gpbb3.pdf
    http://66.35.216.85/gpbb4.pdf
    http://66.35.216.85/gpbb5.pdf
    http://66.35.216.85/gpbb6.pdf
    http://66.35.216.85/gpbb7.pdf
    http://66.35.216.85/gpbb8.pdf
    http://66.35.216.85/gpbb9.pdf
    http://66.35.216.85/gpbb10.pdf
    http://66.35.216.85/gpbb11.pdf
    http://66.35.216.85/gpbb12.pdf
    http://66.35.216.85/gpbb13.pdf
    http://66.35.216.85/gpbb14.pdf
    http://66.35.216.85/gpbb15.pdf
    http://66.35.216.85/gpbb16.pdf
    http://66.35.216.85/gpbb17.pdf
    http://66.35.216.85/gpbb18.pdf
    http://66.35.216.85/gpbb19.pdf
    http://66.35.216.85/gpbb20.pdf
    http://66.35.216.85/gpbb21.pdf
    http://66.35.216.85/gpbb22.pdf
    http://66.35.216.85/gpbb23.pdf
    http://66.35.216.85/gpbb24.pdf
    http://66.35.216.85/gpbb25.pdf
    http://66.35.216.85/gpbb26.pdf
    http://66.35.216.85/gpbb27.pdf
    http://66.35.216.85/gpbb28.pdf
    http://66.35.216.85/gpbb29.pdf
    http://66.35.216.85/gpbb30.pdf
    http://66.35.216.85/gpbb31.pdf
    http://66.35.216.85/gpbb32.pdf
    http://66.35.216.85/gpbb33.pdf
    http://66.35.216.85/gpbb34.pdf
    http://66.35.216.85/gpbb35.pdf
    http://66.35.216.85/gpbb36.pdf
    http://66.35.216.85/gpbb37.pdf
    http://66.35.216.85/gpbb38.pdf
    http://66.35.216.85/gpbb39.pdf
    http://66.35.216.85/gpbb40.pdf
    http://66.35.216.85/gpbb41.pdf
    http://66.35.216.85/gpbb42.pdf
    http://66.35.216.85/gpbb43.pdf
    http://66.35.216.85/gpbb44.pdf
    http://66.35.216.85/gpbb45.pdf
    http://66.35.216.85/gpbb46.pdf
    http://66.35.216.85/gpbb47.pdf
    http://66.35.216.85/gpbb48.pdf
    http://66.35.216.85/gpbb49.pdf
    http://66.35.216.85/gpbb50.pdf
    http://66.35.216.85/gpbb51.pdf
    http://66.35.216.85/gpbb52.pdf
    http://66.35.216.85/gpbb53.pdf
    http://66.35.216.85/gpbb54.pdf
    http://66.35.216.85/gpbb55.pdf
    http://66.35.216.85/gpbb56.pdf
    http://66.35.216.85/gpbb57.pdf
    http://66.35.216.85/gpbb58.pdf
    http://66.35.216.85/gpbb59.pdf
    http://66.35.216.85/gpbb60.pdf
    http://66.35.216.85/gpbb61.pdf
    http://66.35.216.85/gpbb62.pdf
    http://66.35.216.85/gpbb63.pdf
    http://66.35.216.85/gpbb64.pdf
    http://66.35.216.85/gpbb65.pdf
    http://66.35.216.85/gpbb66.pdf
    http://66.35.216.85/gpbb67.pdf
    http://66.35.216.85/gpbb68.pdf
    http://66.35.216.85/gpbb69.pdf
    http://66.35.216.85/gpbb70.pdf
    http://66.35.216.85/gpbbaftr.pdf
    http://66.35.216.85/gpbbindx.pdf
  • by ryants ( 310088 ) on Friday March 23, 2001 @12:07PM (#344067)
    Hopefully Abrash's lead will start a trend among authors of out-of-print books... or even authors of still-printing books.

    Ryan T. Sammartino

  • on the CPUs of today, you also want to avoid the conditional jumps that pester Bresenham's. These can be just as expensive as divides.

  • I just managed to download the cover! Wow! It came down quickly (100 Kb/s) when it finally started. The rest of the chapters are still dead, though :(

    If I _knew_ they wouldn't ever pull the links I wouldn't download it, but that has happaned one time too many. :(((((

  • (vaguely related: damn I wish somebody would "back port" the "//" comment notation from C++ to C. So much quicker to type for those quick one-liners to explain a small point...)

    Not to mention that it makes it A LOT easier to comment out a few lines of code - you surrond the lines to comment out with /* and */, and it works EVEN if there are comments (of the // type) inside the block. This is a thing that really makes me hate people who use /* */ as comment inside the code.
    Oh, and vaguely related: People who in C++ insist on not defining the loop variable inside the for() statement, when it isn't used anywhere except in the loop (or not at all except as a counter). Scenario: Have several of these for loops (unnested) in a function. Comment out around the first one. Now the second one doesn't have the counter variable defined. Hate it. Oh well..

  • That would be a solution yes. I don't like it - if for no other reason, the syntax highlighting doesn't show me what parts were 'commented out'. For that reason, if it isn't too much code, I'd rather enjoy the pain of having to change the comments, constantly cursing the author. :(

  • Site as of 31March2001:


    Along with Michael Abrash, we're delighted to make Graphics Programming Black Book freely available for you. However, the unprecedented and unexpected huge number of downloads and requests has brought us (and our related sites) to our online knees. We apologize for this. We thought that by putting the PDF files for the book by themselves on a dual-Pentium Linux-based server along with a high-bandwidth connection, we would be able to painlessly deliver the book to you.

    Alas, the demand has outstripped even the best of planning. Consequently, we've had to take the book
    down temporarily and put together a better plan for distributing it to you. We should have the entire book back up in a couple of days. Part of our plan will include mirror sites. If you have (or know of) a site that could serve as a mirror, we'd appreciate hearing from you. Please drop us a note at editors@ddj.com [mailto].

    Again, we apologize for the inconvenience and we look forward to freely providing the book to you
    shortly. Thanks for your patience and please check back in a day or so.

    Sincerely,

    Jonathan Erickson
    Editor-in-chief
    Dr. Dobb's Journal
  • I think assembly saves a lot of man-hours (eg. mega bucks) because assembly doesn't need any comments or fancy design. Design and comments waste:
    • A lot of whiteboard markers.
    • You have to spend soooo much painful gruelling time describing boring things.
    • When you edit your commenting, say, changing a sentence, the change cascades down, ruining all the nicely lined up ******** asteriskses, and so you have to redo them all, line by line.
    By avoiding just these three boring and very ardurous tasks by coding in assembly (since assembly doesn't need commenting or program design) the world could save mind-boggling amounts of money. Nevermind how much faster all our code would be!
  • The first half of this book *is* the Zen of Assembly programming...

    On the plus, I don't have to put my back out everytime I pick it up now... (it ways a fucking ton)
  • That's a very ignorant thing to say. Sure, assembly doesn't scale across architectures and isn't portable to the web, but even in this day of multi-platform, web based programming, there are some tasks that assembler excells at where other languages fall behind.

    I'm an experienced programmer, who writes mainly Visual Basic and Java, but I use assembler occasionally for operations where speed and efficency are crucial.

    For instance, if you're writing software to encode DivX;), you will most likely want to drop all the object oriented crap for assembler. Even if it only saves two or three processor cycles for each cycle through the loop, you're going to notice that difference signifigantly for repetitive, processor intensive tasks such as this.

    Assembler is STILL useful and necessary.

  • I'm getting into graphics programming right now - what is Bresenham's algorithm?

    --
    "May the forces of evil become confused on the way to your house"

  • Unfortunately, I think they need the publisher's permission. That would at least kill the still-in-print books. Also, publishers are reluctant to do that, since they figure some won't buy the book if they know it'll be free a year or two later.
  • A good programmer knows what is going on in his programs.

    I believe profilers, debuggers, and optimizing compilers are vastly overrated. Profilers are primarily valuable for finding horribly inefficient code you assumed wouldn't be used enough to matter, then forgot about. Alternative? Never write horribly inefficient code. A little extra effort of keeping code clean and efficient often helps avoid bugs, too.

    I fall firmly into the "debuggers are a seductive waste of time" category. The effort of guessing what is wrong is good training that gives you more awareness and control of your programs. The action of setting breakpoints and stepping through the code is more time-consuming than you may realize, and I don't believe it usually speeds up debugging.

    Optimizing compilers might give you an extra 2X performance boost over all your code, but usually 0.1% of your code covers 99% of run-time, and if you hand-optimize that 0.1% you can usually get at least an 8X boost. More importantly, knowing the hardware intimately tells you what kind of algorithms will be efficient. For example: how expensive are function-pointer calls as compared to conditional branches? What kind of looped conditional structures will screw up the pipeline? How small a block can you access randomly without causing cache misses? Are multiplications really more expensive than additions? Et c.

    These toys are no substitute for your skills as a programmer, and depending on them blunts those very skills.
    --
  • IIRC, entitled: "Wu'd in Haste; Fried, Stewed at Leisure"
    --
  • Optimizing compilers aren't bad, they're overrated. Some people depend on them too much and tell newbies "don't even bother with assembler; the optimizing compiler does a better job than you ever will."

    how did you find out where that 99% of your run-time was spent? In the profiler.

    ...if you're a sloppy hack who has no idea what's going on in his program.

    better algorithms and data structures in the general case

    I don't know about you, but I generally try to get the best algorithms and data structures I can in the first place, for the performance-critical portions, and decent ones in other situations.

    The only time you should have to resort to assembly is when you have absolutely performance critical tasks, ie Interrupt Service Routines.

    I agree that it is best to avoid assembler when possible, but different people have different ideas about performance-critical tasks. More importantly, if you don't do serious work in assembler sometimes, you won't understand the machine.

    Basically, you're advocating the tools of a sloppy style of "slap it together, get it running, then try to make work well later" which also is sloppy in terms of skill development. Doing a half-assed job to get things out the door today might seem worthwhile now, but you never learn to do anything but a half-assed job. That attitude is why most software is bug-ridden bloated crap and most programmers aren't capable of anything else.
    --
  • It's a beautiful illustration of the gains you can make from having a full understanding of trivial processes such as arithmetic. Lots of programmers couldn't even get fixed point math from integers without a recipe book, let alone implement a floating point struct using only ints. They don't even see why to learn either, until they see something like this.

    I thought I had a good understanding of computer arithmetic (I mean, fixed point was no problem, I could write a bignum in my sleep...) until I read Chapter 4 of Knuth's TAoCP. What an eye opener! It replaced all my little tricks with a comprehensive understanding of fundamentals.
    --
  • Bresenhan's algorithm is a fast, simple (jaggy)line-drawing algorithm. Basically, you figure out the longer dimension and step along it pixel by pixel, keeping track of how far off you are getting from the logical line (the "error"); when you're more than half a pixel out, you move one pixel along the shorter dimension.

    The clever bit is finding ways to keep track of the error without using division.

    While line drawing is fairly trivial, often accelerated, and usually handled by libraries, it's also good for figuring out paths of moving sprites and many other tasks similar to line drawing.

    Read about it in the Black Book and immerse yourself in the coolness.
    --
  • by Flying Headless Goku ( 411378 ) on Friday March 23, 2001 @12:18PM (#344083) Homepage
    I have a treasured old copy of "Zen of Graphics Programming", which was the book that introduced me to such beauties as Bresenham's algorithm and dirty rectangle animation. This guy will get your enthusiasm up for graphics the way Knuth teaches a love of elegant, efficient data structures and algorithms.

    Somehow, I never got around to buying the Black Book, though. I read his articles on the Quake engine though, and they're as relevant today as they were the day they were printed (not that low-level engine design is relevant to a huge audience, but at the least it's a good workout for your brain). Definitely worth the bother to download and read.

    Let's try not to all download at the same time, ok? They'll still be there a month from now. They really should have put up a clear notice giving permission to make mirrors; demand is sure to be as crushing as the shipping accident that decapitated me.
    --
  • I coauthored "Oracle8 & Windows NT Black Book" a while back (3 years ago), and it was recently taken out of print. Yeah, it's dated, but a lot of the topics still apply to Oracle8i. Even if you're not an NT person, you'd still learn something about Oracle from reading the book. Trouble is, you can't read it anymore.

    Would anyone here be interested in "open-sourcing" this title? If so, maybe I/we can work on lobbying Coriolis (the publisher) to do so. I have no further financial interest in it, and Coriolis obviously doesn't - so if you like this idea, please reply.

    Thanx... -Mike C.

    (PS- *please* don't reply if you want to debate the merits of NT vs. *nix, or Oracle vs. other DBMS's. My purpose here is to contribute something that might be useful, not get into a flame war.)

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Working...