T w e n t y S i d e d

The procedural city project resulted in a lot of people emailing me who wanted to know how to get into programming. How to learn? What language? What books are most useful? How do you learn about graphics programming, specifically?

Those are all big questions. I guess the first thing I’d do is make sure you know what you’re getting into. Graphics programming is a very specific sub-discipline of general programming, and jumping right to the graphics stuff is a bit like trying to learn heart surgery before becoming a doctor. It can certainly be done if you really want to learn that way. (Unlike heart surgery, you don’t have to worry about being sued by bereaved next-of-kin for your newbie mistakes. You’ll just crash people’s computers. And Microsoft has proven you can’t go broke doing that.) But jumping into “graphics programming” before learning “programming” is probably not the smoothest route to knowledge. Learning programming isn’t quite the mental challenge medicine is (one assumes, judging by their relative salaries) but like any body of knowledge it does take time to acquire.

Aside from a few COBOL courses in school, I’m entirely self-taught. (The one language I was taught – twice – is the one language I don’t know. I couldn’t generate a single valid line of COBOL to this day.) I imagine the self-taught route is what you have in mind if you’re emailing me. If you were looking for formal education then you’d probably see your guidance counselor or shop for a college. Being an autodidact is fine for enriching your knowledge and understanding of the world, but slightly bad if you’re looking for a career. Even at 37, my earning potential is probably lower than someone with the same experience who can wave around a ~4 year degree. Whether or not that increased earning potential of a degree is worth the risk and expense of taking out loans to pay for one is a really complex question. I come down pretty firmly on the “no” side of the argument, but a lot of coders would argue with me. And the successful ones generally make a lot more than I do. QED.

Jumping in and learning a modern professional-grade language can be a bit much. In the 80’s, most kids were introduced to something much simpler, like BASIC, Logo, or (if they’re quite young) Turtle. I don’t know what kids are taught these days. The point of learning one of these simpler languages is to teach you the basic premise behind programming without getting too bogged down with technical details at the outset. Once you have your head around the idea that source code is a list of instructions that the computer will follow unerringly no matter how wrong they are or what you really intended, you have the basic tools to go learn something useful. It’s a bit like learning to play the piano before you learn another instrument. A piano provides an obvious and straightforward expression of the notes at your disposal, and you’ll usually have gotten a head full of music theory by the time you’ve learned to operate the thing. Then you’ll have a nice foundation to work with while you learn something less straightforward, like string instruments or anything powered by your lungs. In any case, this is a tradeoff: You’re reducing the steepness of the learning curve in exchange for making it longer.

So, assuming you want to learn some graphics programming, don’t mind investing time in generalized programming first, aren’t afraid of a steep learning curve, and aren’t looking to score a degree, then my advice may be of some use to you.

C++ is a good starting language, although there are enthusiastic adherents to many other languages. C# and Python are notable in that both of them can be used to write modern graphics programs. I still recommend going for C++, if for no other reason than the network effect will make it easier to find tutorials. Working in C++ also makes it easier to find unhelpful jerks who will offer snarky answers to earnest questions, which is a major improvement over the smaller languages where you won’t be able to find anyone at all.

I suggest starting with Teach Yourself C++ in 21 Days. Partly because it’s a great book (aside from some nitpicks with the way and the rate at which complex concepts are introduced) but mostly because it’s freely available online. You can also get a dead tree copy, which can be handy. Don’t be put off by the “21 days” stuff. You can blow through the first half-dozen lessons in an afternoon. Things will slow down after that, but the “21 days” stuff is by no means a hard figure and can vary a great deal on how much prior knowledge you have going in and how much time you put into it. I’ve purchased a few copies of the book and given them away to aspiring young programmers over the years.

Sadly, I’ve never found good books or tutorials that teach the concepts beyond language syntax. So, after your 21 days you’ll know how to write a program to balance your checkbook or play blackjack, but you’ll still have no idea how to structure your program by breaking it up into different modules. (That’s fancy programmer talk for putting the source code into different text files.) You’ll have learned nothing of the code formatting holy wars or the particulars of the 1,487 different ways to name variables, each of which has their own zealous adherents. You won’t know about LIB files, what they are, or how to use them. You won’t know about development environments, or MAKE files, or how to read a debug stack. You’ll probably have some idea of what a DLL file is (all windows users have those things floating around on their hard drives like so much driftwood) but you won’t know how to link to one. You won’t know how to really debug your program. (Although you’ll think you will.)

That stuff is 90% of the job, and all of the books and tutorials are focused on that first 10% of learning language syntax and knowing what to type. There are books for refining existing skills in some of those areas, but they’re very much deep-end books that will lose a newcomer in a few pages. We have lots of articles for turning people into programmers, but very little for making them any good.

Thankfully, you can pick up most of that higher-level stuff as you go. I did. (Although I still can’t make use of a debug stack, even after all these years. And it’s not for lack of searching for someone who can explain it in English.)

Once you have some basic knowledge of C++ programming, you’re ready for the graphics stuff. At this point, there is no better place to go than NeHe productions. This is where I went to learn OpenGL. The tutorials on NeHe are some of the best programming tutorials you’ll read. It’s true that most tutorials suck, but the ones at NeHe (particularly the early ones) are simple, compact, straightforward, generously documented, and fun. You can simply download the code and make use of it, or you can read through it on the site along with the instructor’s commentary and explanations. (I highly recommend the latter.)

The site will let you learn by reading the commentary. Or you can learn by example through reading the code. Or you can learn by doing by playing around with (say) lesson 3 and seeing what happens when you plug different numbers in. NeHe isn’t just a collection of the best graphics tutorials around, it’s some of the best programming tutorials of any kind, period. It’s a site that focuses on teaching, rather then simply shoveling information in your direction.

Good luck.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.