Michael Abrash's Graphics Programming Black Book
orangetide.com
orangetide.com
Oh, and laichzeit0 - my apologies to your dad for the weight of the book. There have been a few times when I was lugging one around and wishing I had been more sparing with the words :)
--Michael
At the time I didn't understand much of it but I remember the evolution of him optimizing Boyer Moore string search left quite an impact. That and the anecdotes of him working with John Carmack at the time they were coding Quake I. Just browsing through the chapters makes me want to read the whole thing again.
http://www.drdobbs.com/parallel/graphics-programming-black-b...
I think you should read the first chapter at least, on how he approaches code optimization, first by design and then by code.
This book teaches you to think like a performance programmer like no other. In the first chapter he challenges assumptions, for example how lib C code is not really optimally written (its written for portability and general purposes) and you can easily write more efficient algorithm to do the same.
The mindset of not being at mercy of the library is a powerful one, it inspires you to dig deeper and find out how things really work. Thus, you make the best choices for the problem in hand.
John Carmack, for example, didn't write much of his games in assembler because he knew that he didn't have to. If you look at Doom, there wasn't a lot of assembler even back in the early 1990's.
https://github.com/id-Software/DOOM
And according to Carmack, he liked working in C and OpenGL.
http://rmitz.org/carmack.on.opengl.html
"With OpenGL, you can get something working with simple, straightforward code, then if it is warranted, you can convert to display lists or vertex arrays for max performance (although the difference usually isn't that large). This is the right way of doing things -- like converting your crucial functions to assembly language after doing all your development in C."
I actually have done some basic assembler so I do understatnd the benefits of keeping values in registers, etc. A lot of stuff really is architecture dependent, of course. ARM vs x86 will make a difference.
Anyway, where's the best place to start these days? Personally, I'd like to do some iOS stuff, and perhaps keep the same code running on Android.
Then I'd advice either reading a general rendering book or some GPU docs depending on your finding the book too easy or too hard.
http://www.amazon.com/OpenGL-Programming-Guide-Official-Lear...
When I googled it, the red book was not recommended. OpenGL 3.x has many changes that aren't covered?
http://www.gamedev.net/topic/601531-best-book-to-teach-openg...
[Update] Here are three good references that I extracted:
http://nopper.tv/norbert/opengl.html
http://www.amazon.com/Beginning-OpenGL-Programming-Second-Ed... -- Mixed reviews
http://www.amazon.com/OpenGL-SuperBible-Comprehensive-Tutori...
I checked and Android 4.3 supports 3.0. KitKat's low memory support should mean that even new cheaper phones will get Android 4.4 in the near future.
OpenGL 3.x seems like a dead end IMHO. I only follow the Kronos group antics as a spectator, so I might be completely wrong but it seems the 4.x is trying to clean the mess of 3.0 and not building over it. It could also be the reason the 3.x redbook did not get enough Amazon stars for your satisfaction.
There are a lot of options such as unity, haxe/openfl, adobe air, etc. Most of these are very easy to pick up by just reading one of the many online tutorials.
Back then this was a goldmine of tricks.
But I'm sure the algorithm parts are still relevant.
Apart from that it's a nice read and some of the outdated parts might be skipped.
Those are lessons that are still relevant today.
(snark-free version: that book would be a lot better if it was finished... note the last edit was over a year ago)