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."
Good stuff (Score:1)
Summary of the Book (Score:1)
OPTIMIZATION IS AN EMPIRICAL SCIENCE
MICHAEL ABRASH IS A "COOL" GUY
That should save Dr Dobbs a few gigs of bandwidth.
Re:Put it in a museum (Score:1)
Re:Put it in a museum (Score:1)
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).
new publishing strategy... (Score:1)
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.
Re:oh... (Score:2)
Re:Boon to Linux (Score:1)
Re:Gadzooks... (Score:1)
Re:Put it in a museum (Score:1)
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. :-)
Nonsense. (Score:1)
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 paid full price.... :( (Score:1)
It is great to see (Score:1)
Re:feh. (Score:2)
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.
Re:Bah! Toy-based development! (Score:2)
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).
Re:Bah! Toy-based development! (Score:1)
Re:Looking forward to downloading this (Score:1)
http://www.cs.washington.edu/research/projects/ce
And maybe start from:
http://www.cs.washington.edu/research/projects/ce
Re:Michael Abrash-- (Score:3)
Re:Bah! Toy-based development! (Score:1)
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.
Re:Bah! Toy-based development! (Score:1)
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.
Re:Looking forward to downloading this (Score:3)
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.
Borders had this a short time ago for cheap (Score:1)
Re:Bresenham's algorithm in a nutshell. (Score:4)
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
oh... (Score:2)
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.
--
Re:Bresenham's algorithm in a nutshell. (Score:2)
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.
Re:Bah! Toy-based development! (Score:1)
Re:Bresenham's algorithm in a nutshell. (Score:1)
-Puk
p.s. It wasn't a chair.
Solid Foundation for design & optimization (Score:3)
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.
Good book (Score:1)
Mirrors (Score:1)
multi-line comment tip (Score:1)
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]
Re:multi-line comment tip (Score:1)
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]
Re: (Score:1)
wah =( (Score:1)
Why God why?
--
Peace,
Lord Omlette
ICQ# 77863057
no (Score:1)
--
Peace,
Lord Omlette
ICQ# 77863057
Re:wah =( (Score:1)
--
Peace,
Lord Omlette
ICQ# 77863057
Re:Summary of the Book (Score:1)
¹Commenting out code: use #if 0 instead (Score:1)
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
more on multi-line comments (Score:2)
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.
Damn. (Score:1)
Re:pdf? (Score:1)
--
Re:pdf? (Score:2)
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.
Re:Other "Black Book" titles (Score:1)
Since the site seems to be Slashdotted already (Score:5)
http://www.bluesnews.com/abrash/ [bluesnews.com]
Michael Abrash enters my life again... (Score:1)
Re:You must be a devil with the ladies! (Score:1)
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.
Looking forward to downloading this (Score:2)
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.
So if I can tell parables (Score:1)
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?
----
Re:wah =( (Score:1)
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
Re:Damn. (Score:1)
Mirrors available (Score:1)
Re:wah =( (Score:1)
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.
Re:Sweeeet. (Score:1)
--
"Chiswick! Fresh horses!"
Re:Bah! Toy-based development! (Score:2)
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.
Re:pdf? (Score:2)
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
Best book...probably. (Score:3)
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.)
A great bible, but outdated. (Score:1)
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.
Re:Since the site seems to be Slashdotted already (Score:3)
Michael Abrash-- (Score:1)
-- 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.
Re:Michael Abrash-- (Score:1)
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..
Re:Put it in a museum (Score:2)
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'.
Re:Sweeeet. (Score:1)
Digital doorstop (Score:1)
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.
Re:feh. (Score:1)
Re:Borders had this a short time ago for cheap (Score:1)
Up There With Computer Graphics: Principles and Pr (Score:1)
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!
Michael, time to get free (Score:1)
--
Re:Damn. (Score:1)
---
Re:Boon to Linux (Score:1)
NO, i don't think it's a Troll.
Well, i should not respond, but i can't control myself.
Ricky
Re:pdf? (Score:1)
Most people convert TeX into PostScript file.
Ricky
Re:Bah! Toy-based development! (Score:1)
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
Re:Great book (Score:2)
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.
Re:Put it in a museum (Score:3)
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.
Use wget (links here) (Score:1)
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
Hopefully starts a trend (Score:3)
Ryan T. Sammartino
A small side note (Score:1)
Re:Damn. (Score:1)
If I _knew_ they wouldn't ever pull the links I wouldn't download it, but that has happaned one time too many.
Re:multi-line comment tip (Score:1)
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
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..
Re:¹Commenting out code: use #if 0 instead (Score:1)
/.ed--looking for mirrors (Score:1)
Re: Re: Put it in a museum (Score:1)
Re:Good stuff (Score:1)
On the plus, I don't have to put my back out everytime I pick it up now... (it ways a fucking ton)
Re:Put it in a museum (Score:1)
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.
Re:Sweeeet. (Score:1)
--
"May the forces of evil become confused on the way to your house"
Re:Hopefully starts a trend (Score:1)
Bah! Toy-based development! (Score:1)
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.
--
Um... That's in the Black Book too. (Score:1)
--
Re:Bah! Toy-based development! (Score:1)
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.
--
Yeah, that's the clever bit. (Score:1)
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.
--
Bresenham's algorithm in a nutshell. (Score:3)
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.
--
Sweeeet. (Score:5)
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.
--
Other "Black Book" titles (Score:2)
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.)