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

51–60 of 85 posts

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

#51

Post by reddickulous »

mumblemumble wrote: post #49
anaphor wrote: post #34

Earlier quoted context omitted.

I've had people tell me all of the extra bloat/slowness in modern software is because it has more features, and because accessibility / localization is a thing more often. I'm not sure I actually believe that's true. Maybe accessibility and localization contributes to bloat/slowness, but that doesn't mean it couldn't be much much more efficient and keep the same features.

> I've had people tell me all of the extra bloat/slowness in modern software is because it has more features Lately I've been making something of a hobby of replacing big scale-out Apache Spark ETL jobs with stuff that was hand-coded to use something other than Spark. Generally I'm finding that, with a little care, I can get a lot of these jobs done in less time on a single machine than I can running it on the Spark…

It's a lot easier to hire someone to drive a box truck than it is to hire someone to drive your Kia.

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

#52

Post by hgoel »

tombert wrote: post #42
anaphor wrote: post #34

Earlier quoted context omitted.

I've had people tell me all of the extra bloat/slowness in modern software is because it has more features, and because accessibility / localization is a thing more often. I'm not sure I actually believe that's true. Maybe accessibility and localization contributes to bloat/slowness, but that doesn't mean it couldn't be much much more efficient and keep the same features.

I think people undersell the value of safety. Back in the 80's and 90's, it wasn't uncommon to drop into assembly to grab every last cycle of performance, since computers were so slow. We also didn't do garbage collection, and people were writing in languages like C and C++. Software from then was also prone to random crashes and freezes, which doesn't happen so much anymore. We've started to come around with languag…

One can have safety without the absurd bloat though.

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

#54

Post by tombert »

hgoel wrote: post #52
tombert wrote: post #42

Earlier quoted context omitted.

I think people undersell the value of safety. Back in the 80's and 90's, it wasn't uncommon to drop into assembly to grab every last cycle of performance, since computers were so slow. We also didn't do garbage collection, and people were writing in languages like C and C++. Software from then was also prone to random crashes and freezes, which doesn't happen so much anymore. We've started to come around with languag…

One can have safety without the absurd bloat though.

I agree with you in theory (hence why I gave a nod to Rust), but I think it's easier to have safe, bloated software. I think newer languages like Rust and Swift definitely are demonstrating the ability to have lean software that is just as fast as something written in C, but these are still relatively new in the scope of things.

Much as I think Java is a garbage language, there's no doubt that, by default, it's safer than a program written in C. It also typically is bigger, requiring a bit more RAM and resources.

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

#55

Post by Junk_Collector »

ben7799 wrote: post #31

This is such an awesome book. I read this back in the day and loved every minute of it. I think there is a lot to learn from it still, even if you're highly unlikely to be writing the same kind of graphics code. The book has a great balance between: - Micro-optimization - fiddling with ASM and data structures, memory alignment and such, custom math functions that lose precision in tradeoff for great acceleration due…

User interfaces are measurably slower than they were 20 years ago by at least an order of magnitude depending on how you measure it. They also do more, so it's up to the particular user and use case to decide if the trade off was good.

There was someone who said something along the lines of, "Heaven is old software on new hardware" and I personally agree with them.

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

#56

Post by pronoiac »

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.

Out of curiosity, how did you do the html to markdown conversion?

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

#57

Post by codesushi42 »

Accujack wrote: post #41
anaphor wrote: post #34

Earlier quoted context omitted.

I've had people tell me all of the extra bloat/slowness in modern software is because it has more features, and because accessibility / localization is a thing more often. I'm not sure I actually believe that's true. Maybe accessibility and localization contributes to bloat/slowness, but that doesn't mean it couldn't be much much more efficient and keep the same features.

Present day programs aren't optimized because they don't have to be. No one needs to gain a competitive advantage by squeezing the last bit of performance out of hardware because for a long time we've had steadily increasing performance levels and backward compatibility. Applications which need more performance than the present level of hardware can deliver so badly that they need to optimize to that level are very r…

I disagree. Software nowadays is atrocious because it's not optimized. It's just that average users have become more accepting of long load times and bloat.

Here's an example. In the mid to late 90s, gamers would complain a lot about load times for CD ROM games. For some gamers, the load times were a deal breaker. This was one reason Nintendo could get away with using cartridges on the N64.

Fast forward to the present, and load times for many mainstream games is FAR worse than the 1-2x speed CD based consoles of the 90s. And a lot of this is due to sloppy, unoptimized code, e.g. loading assets. And yet no one bats an eye.

Another example is the web. There are so many garbage, unoptimized sites that load on my smartphone as if I were on dial up (I'm looking at you, Gawker). Yes, those pages contain a lot more multimedia content nowadays, but they still load at the same rate as a typical page in the 90s would have on dial up.

And with Moore's Law now ending (ended?), optimization may come back in vogue.

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

#58

Post by [deleted] »

reddickulous wrote: post #51
mumblemumble wrote: post #49

Earlier quoted context omitted.

> I've had people tell me all of the extra bloat/slowness in modern software is because it has more features Lately I've been making something of a hobby of replacing big scale-out Apache Spark ETL jobs with stuff that was hand-coded to use something other than Spark. Generally I'm finding that, with a little care, I can get a lot of these jobs done in less time on a single machine than I can running it on the Spark…

It's a lot easier to hire someone to drive a box truck than it is to hire someone to drive your Kia.

[deleted]

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

#59

Post by bitwize »

codesushi42 wrote: post #57
Accujack wrote: post #41

Earlier quoted context omitted.

Present day programs aren't optimized because they don't have to be. No one needs to gain a competitive advantage by squeezing the last bit of performance out of hardware because for a long time we've had steadily increasing performance levels and backward compatibility. Applications which need more performance than the present level of hardware can deliver so badly that they need to optimize to that level are very r…

I disagree. Software nowadays is atrocious because it's not optimized. It's just that average users have become more accepting of long load times and bloat. Here's an example. In the mid to late 90s, gamers would complain a lot about load times for CD ROM games. For some gamers, the load times were a deal breaker. This was one reason Nintendo could get away with using cartridges on the N64. Fast forward to the presen…

The N64 lost its console generation and solidified Sony as the market leader, in part because it used cartridges while everyone else used CD-ROMs. Way to choose an example that disproves the very point you were trying to make.

As for load times today, most modern games are implemented as scripts and assets for one of the big engines, usually Unreal or Unity. It's hard enough to manage all the assets that go into a modern game; an optimized loader would just make wrangling them all even more difficult.

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

#60

Post by emptybits »

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.

OP here. Sorry if there was confusion. I came across your repo and was giddy with excitement to see it and wanted to immediately tell the world! :-) This book was a big deal for me in the late 1990s, still working as a game programmer. My copies were lost or loaned and I think I heard angels sing (or tracker/chip tunes?) when I discovered your repo. ;-)

I suffixed the headline "2019 V1.1 Release", trying for some clarity, since that was the most recent event I saw in the repo. Then it was re-headlined by someone else because that was also, apparently, confusing. Sorry! But THANK YOU for your work!

Post reply on HN