February 27th, 2012 12:52 AM
I've been really digging into OpenGL ES 2 lately, since I love to work with graphics, and my current depth of knowledge seems to be about a decade out of date. It is pretty amazing how far things have moved on from OpenGL 1, which is somewhat sad, because it renders a large swath of my own knowledge effectively useless. Oh, some fancy ARB multitexturing? display lists? that's adorable, now write it with shaders. There aren't even vertex buffers, just buffers which you have to segment yourself in whatever ways you might desire. Of course, this brings with it some really exciting implications concerning the data you can bundle along with each vertex, plus it's absolutely as fast as it can be and can run on a phone. It definitely took a while to wrap my head around shaders and the loss of everything familiar.
One really useful recommendation I found was to just plain read the specs. Usually, my first impulse in getting my feet wet in a subject is not to bust out a full specification of the language -- that sounds like learning how to drive by grabbing a car manufacturer's parts sheet. But I read a lot of "helpful" articles online, and nothing mushed my brains about into the correct configuration quite like the OpenGL ES Shading Language spec itself. I printed out a copy, and even bound it myself with a knife and some twine, so I could bring it around with me. Nothing seems to really set off the nerd alert like bringing a spec sheet everywhere you go. But it worked! Getting to know the requirements of the shading language really helped spell out all the differences I needed to learn about. I can say, honestly, that I understand OpenGL ES at least 12%. Enough to make a full game engine!!
Definitely still more to figure out (that's what the OpenGL ES spec is for!), but I've managed to write up some junk that actually compiles both for Windows and my phone, the Palm Pre 3. I made my phone's screen turn orange! It was amazing let me tell you! No textures yet for the phone, as I still haven't figured out how to package more than an executable, but whatever!
My latest nonsense has been taking what I've learned to create some kind of sprite rendering job dispatch system, so that the crazy buffers and such are all abstracted away from the concept of rendering sprites. It was the kind of system where it's about a thousand lines of code that really can't be tested until all the various parts are all completely connected, and to my own great astonishment, apart from forgetting to bound the number of items, it worked pretty much right off the bat. Now I'm back where I was like a decade ago with Bumfight! Except this time the code isn't a huge spaghetti dinner. Seriously, I'm using some of the niftier algorithms I threw into that program, but wading through that codebase is incredibly painful. I was constantly doing things like having the user-input system holding onto pointers to objects in the game's map so it can respond to inputs differently based on what's going on in the game. What the heck! Every system had long knobbly fingers stretched and jammed into every other system.
What I've got so far is a joy to work on, and it's actually using graphics technology from the correct decade, to boot. I even have it under version control! It's almost like I do this sort of thing as a career!