Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graphics Programming Black Book by Michael Abrash (2001)

github.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Graphics Programming Black Book by Michael Abrash (2001)

#21

Post by naikrovek »

ArtWomb wrote: post #20
Shish2k wrote: post #18

"Is performance still an issue in this era of cheap 486 computers and super-fast Pentium computers? You bet. How many programs that you use really run so fast that you wouldn't be happier if they ran faster? We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less tha…

People take for granted that an app responds in milliseconds. Engineers at Google, et al, of course immediately recognized that performance was tied to adoption in the early days and left no stone unturned in their quest for optimizations. The analogy today in portable devices is maybe with battery life drain during game play.

I think with search results you're right, and with things like GMail it seems performance is at the bottom of the priority list. Perhaps even off of the priority list entirely.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#22

Post by bjourne »

markus_zhang wrote: post #16
taneq wrote: post #11

Earlier quoted context omitted.

I don't think I'll ever be disappointed to see this work linked. :) In some ways I feel like modern graphics programming has little to do with traditional optimisation. Rather than coding tight inner loops and wizardly algorithms, it's all about managing cache lines and pipelining data flows into your massively parallel desktop supercomputer. Which is awesome, but compared to the older stuff it's like a high speed ra…

Just curious, is it OK to say that most of the book is irrelevant for today?

Yup. I bought the book after it came out and threw it away a few years ago. Most of the material in the book (like the peculiarities of 320x200 vs 320x240 VGA mode) hasn't aged very well. But that's the name of the game. You can't write truly optimal code without knowing all the details of the hw you are targeting.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#23

Post by remon »

Ono-Sendai wrote: post #19
raverbashing wrote: post #13

Earlier quoted context omitted.

I'd add one small thing (from the book): There Ain't No Such Thing as The Fastest Code (A good sum up https://blog.codinghorror.com/there-aint-no-such-thing-as-th... ) There are multiple ways of optimizing a code with different caveats and advantages

Sometimes there is such a thing as the fastest code: http://forwardscattering.org/post/13 Edit: In the black book the 'ain't no such thing as the fastest code' seemed to be a bit of 'folksy' wisdom, illustrated by various anecdotes about fast code being upstaged by yet faster code. However it rubs me a little the wrong way, considering that it's not actually a true statement as demonstrated in my link above.

You're right of course but I think we have to recognise that for all sufficiently complex problems Abrash' "folksy wisdom" is effectively true and, in his particular case, a good chapter title more than a statement of fact.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#24

Post by chongli »

markus_zhang wrote: post #16
taneq wrote: post #11

Earlier quoted context omitted.

I don't think I'll ever be disappointed to see this work linked. :) In some ways I feel like modern graphics programming has little to do with traditional optimisation. Rather than coding tight inner loops and wizardly algorithms, it's all about managing cache lines and pipelining data flows into your massively parallel desktop supercomputer. Which is awesome, but compared to the older stuff it's like a high speed ra…

Just curious, is it OK to say that most of the book is irrelevant for today?

It's not irrelevant unless you intend to focus on modern, triple-A graphics engines. Lots of indie game developers don't care about that stuff! There are even people working on new games using engines from the 90s, such as the Build engine [1]. Ion Fury [2] is one example.

I think the more you focus on modern graphics engines, the more difficult it is to stand out from the crowd. You end up in a rat race where you need a huge team of artists to create all of the assets for your photorealistic game.

On the other hand, with an old engine (or a new engine using traditional rendering techniques), you can make something distinctive and stylish with a smaller team. After all, they say the enemy of art is the absence of limitations.

[1] https://en.wikipedia.org/wiki/Build_(game_engine)

[2] http://www.ionfury.com/

Re: Graphics Programming Black Book by Michael Abrash (2001)

#25

Post by app4soft »

jagregory wrote: post #6
tobr wrote: post #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...

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.

Could you also add PDF version? (converted from Markdown)

Re: Graphics Programming Black Book by Michael Abrash (2001)

#26

Post by tverbeure »

This takes me back to the early nineties, when these articles where published in monthly installments in Doctor Dobbs Journal and, later, PC Techniques.

Incredibly, these 2 magazines were stocked monthly at my local newsstand in a sleepy suburb of Antwerp, Belgium, and every month around publication time, I’d bike there daily to check if the next issue had arrived.

I learned a lot of good stuff in college, but I don’t remember anything as exhilarating as this series, which eventually would lead to a career in the computer graphics industry.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#27

Post by taneq »

markus_zhang wrote: post #16
taneq wrote: post #11

Earlier quoted context omitted.

I don't think I'll ever be disappointed to see this work linked. :) In some ways I feel like modern graphics programming has little to do with traditional optimisation. Rather than coding tight inner loops and wizardly algorithms, it's all about managing cache lines and pipelining data flows into your massively parallel desktop supercomputer. Which is awesome, but compared to the older stuff it's like a high speed ra…

Just curious, is it OK to say that most of the book is irrelevant for today?

The technical details are pretty irrelevant for desktop computers, although there are analogues to some of the techniques on some more recent platforms eg. Gameboy Advance, smartwatches, maybe mobile VR (I do wonder if that's why Carmack is so keen on working on the Oculus Quest).

The way that it walks you through the mindset of optimising code is timeless and well worth reading, though, imo.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#28

Post by taneq »

chongli wrote: post #24
markus_zhang wrote: post #16

Earlier quoted context omitted.

Just curious, is it OK to say that most of the book is irrelevant for today?

It's not irrelevant unless you intend to focus on modern, triple-A graphics engines. Lots of indie game developers don't care about that stuff! There are even people working on new games using engines from the 90s, such as the Build engine [1]. Ion Fury [2] is one example. I think the more you focus on modern graphics engines, the more difficult it is to stand out from the crowd. You end up in a rat race where you ne…

Just to build on this, modern triple-A games are incredibly asset-based. It doesn't matter how good a coder you are, unless you have an art department producing every single tiny little detail of your in-game assets, they're going to look terrible.

This is part of the reason low-fi games are making a comeback in the indie scene, because they can actually look good with only one or two artists working on them (or even sometimes with programmer art.)

Re: Graphics Programming Black Book by Michael Abrash (2001)

#30

Post by pradn »

naikrovek wrote: post #21
ArtWomb wrote: post #20

Earlier quoted context omitted.

People take for granted that an app responds in milliseconds. Engineers at Google, et al, of course immediately recognized that performance was tied to adoption in the early days and left no stone unturned in their quest for optimizations. The analogy today in portable devices is maybe with battery life drain during game play.

I think with search results you're right, and with things like GMail it seems performance is at the bottom of the priority list. Perhaps even off of the priority list entirely.

Performance is just a requirement. If it's good enough, it's good enough to release. It's not ideal and immensely wasteful, but that's how incentives are aligned.
Post reply on HN