Name: OpenGL superbible
ISBN: 9780321902948

What Hacker News says

_gabe_Sep 2023

Math books can be a hit or a miss, but Game Engine Architecture is an amazing overview of all the major systems in a game engine. You’d also be doing yourself a disservice if you didn’t read something like OpenGL Superbible (that book filled in so many gaps in my knowledge and made graphics development so much easier).

As for the rest of your comment I absolutely agree. I wouldn’t discourage anybody from trying to write a game from scratch, but if you want to focus on art style, level design, game mechanics, and being able to easily ship to almost every platform, then I would definitely encourage you to use an engine like Unreal or Unity.

OP made it sound like Hollow Knight could’ve been a great game if only they didn’t use Unity, but I don’t believe that. It is a great game, full stop. It’s like people that complain about electron (which I also tend to agree with) irregardless of whether the final product is any good or not. VSCode is great, in spite of the fact that it was written in Electron. And ultimately, the people buying your games really won’t care how it was made, they’ll just care about how it plays.

thread

_gabe_Aug 2022

> There is also the notion of being able to make better decisions with more "connection material" in your mind. The more you know, the more likely you are to make a novel connection.

I completely agree with this, but I don't believe all blog posts and technical articles are written equal :)

You have:

1. Your garden variety tech blog post about somebody's experience using X or Y framework or just a general techy blog. (I'm thinking a joel spolsky or coding horror post here)

2. A technical dive into a specific problem/framework.

3. A raymond chen style blog post explaining the reasons behind some weird api.

And then you have the deeper material:

4. The Pragmatic Programmer. Not too dense and can still be enjoyed at a leisurely pace, but contains enough deep thinking type of material to motivate you.

5. A comprehensive reference book about a specific framework or concept (Game Engine Architecture and OpenGL SuperBible come to mind).

6. The Art of Computer Programming.

I only consider the last 3 productivity material. The first 3 can be helpful in rare instances, but they're more akin to watching a 3blue1brown video where I say "That was interesting" and proceed to forget all about that topic.

thread

exDM69Nov 2011

This one of the only tutorials on OpenGL that is worth reading. This is the one we recommend at ##opengl in freenode.

Most GL tutorials use deprecated legacy OpenGL 1.x, which is terrible from an efficiency standpoint and has very little to do with modern 3d hardware. In addition to using legacy API's, they are often plain badly written.

The same applies to many books on OpenGL. They use legacy GL and/or are written by clueless people who know very little about the hardware the code runs on. Then they get branded with a silly name like "Writing 3d apps for iPhone", because the books stand no chance in comparison with better GL books.

Don't ask me for book recommendations, I don't really know. The only one I've heard good things about is the very latest edition of the OpenGL Superbible.

thread

octopusNov 2011

Looks like a great first book on OpenGL, written in a tutorial style. One can read this book first and then approach more complex (complete) books like OpenGL SuperBible.

thread

mrcharlesNov 2011

As a long time game programmer, I can tell you that the OpenGL Superbible is the only reference book anyone uses.

thread

10x-devJan 2022

I've been trying to learn how to make games in my spare time on-and-off for 20 years (wow time does fly). Here's my postmortem to serve as a warning for younger versions of me.

My first mistake was underestimating how much math one needs to know. Spoiler: it's all math - mostly linear algebra. That's why any graphics / physics / gamedev book has at least one math chapter. You do need it for everything - from coloring something to making things move on the screen.

My second mistake was not making games. One would think that it would be an obvious thing to do, but it's so easy to underestimate the amount of time it takes to understand graphics programming (in retrospect, just the size and weight of the "Computer Graphics - Principles and Practice" book should have been a gigantic red flag). I ended up writing game engine code instead of game code. Being able to draw triangles on the screen is just not as satisfying for me as making cars chase each other and it also doesn't move the needle on getting a game out the door. In practice this translates to maybe reading "Programming Game AI" instead of "Real-Time Rendering" (given limited spare hours) or actually finishing "Nature of Code" instead of reading "Game Engine Architecture".

Arguably my biggest mistake was being stubborn, but not stubborn enough to persevere through all the crap. Early on I didn't want to use an engine because I generally like to understand things from first principles and I didn't understand how deep the rabbit hole went. It turns out that the first principles in game graphics are closer to a collection of progressively more horrible hacks on how to achieve realism in real time without ray tracing, because that's too slow, and how to patch all the side effects of that reality (don't drop a book on implementing shadows on your feet). People with PhDs describe these techniques in scientific looking papers, which then get discussed at large conferences, referenced in books, etc and normalized. Want to learn a new technique? Read the (dense) paper. Other people decide then to take the best hacks, accelerate them in hardware and expose them as APIs. Decades of optimizations and hacks built on top of each other pushed the entry bar higher and higher, to the point where the amount of complexity one needs to wrap their head around is just not realistic for a beginner, unless they are stubborn enough and diligent enough to persevere through all of it. I should have paid that $100 to use the Torque engine, instead of buying the OpenGL Reference Manual, OpenGL Superbible and the OpenGL Shading Manual.

Lastly I fell into the trap of buying the books, but not working on games, aka "all the gear but no f*cking idea". My shelf is filled with highly regarded books that I read and some I gave up on (because they were over my head). I released 0 games. That said it's a good way to discover gems like "The Ray Tracing Challenge" book. Learning new things is fun and addictive.

I came to the realization that I would have really benefited from having a mentor, a well defined and structured curriculum, and being a bit more humble about my own ability to jump into this field, but, most importantly, I should have just made games - crappy looking, never-going-to-make-money, but fun games. That's why learned to code in the first place, after all.

These days I am using Godot and am finding it easy to use, especially after spending all this time fiddling in the graphics world. However, having children greatly reduced the amount of time I can dedicate to this hobby.

It was rather painful and cathartic to type this out.

P.S. I tell myself I'll find time to read "Physically Based Rendering" (another book that would make a whole in the floor if dropped), "Realtime Collision Detection" (more fun math!) and the newest edition of "Real Time Rendering" (its website is a nice resource to find other graphics books to purchase and never read).

thread