[Back to Personal]


  I've had many emails over the years asking how to get into graphics programming, so instead of writing all those replies, I wrote this article and now I can just point people to it. So here goes.

I grew up in a podunk town in Ohio, where there was no one to teach me this stuff. I was *dying* to know how the Future Crew (a demoscene group) made a 486 crank out such amazing 3D graphics, but my math teachers had no idea how they did it, and weren't able to point me to the right resources. Only when I hit college, my first quarter, did I learn about vector math and dot products, which is basically the foundation of 3D graphics, and then I went ballistic, writing code non-stop, making up for years of deprivation!

The world is different now; we have Google, and you can learn it all sitting at your desk. I wrote this article some time ago (it's now 2006, and I'm updating the intro). But the tips in this article still have some value, so I'm leaving it here.

The unfortunate thing is that learning graphics programming takes a LOT of work: there is a wide base of background knowledge to accumulate (especially in mathematics), LOTS of programming practice time to put in, and a lot of studying of graphics techniques, which add new, more devilish layers of complexity every year.

Another warning: most game programmers work horribly long hours. And sitting in front of a computer 40+ hours a week, for life, can wreck your body (I find regular exercise and especially yoga repeatedly saving my life). Non-game graphics programming jobs can come closer to the fabled 40-hour work week, but even years of that can be hard on your body.

So, if after those scare messages, you're still aspiring, then here are some tips.

Best of luck to you!


Background in algebra and geometry are essential. You can't survive (honorably) as a graphics programmer if you don't know how to derive the equations you'll be using. Sure, you can look it up in a book, but you want to be able to come up with new approaches & algorithms. It would be like trying to be a mechanic but always having to use the manuals.

Calculus is where I learned the brunt of the math that I've used in 3D graphics, though. A lot of things might not make perfect sense at first, or not seem applicable, but try to learn everything you can. You'll need it all. Plus, the more you know, the easier it will get in the future to tie new ideas together. You'll never have the chance again to sit there for an hour a day and have someone EXPLAIN to you how to do all this stuff - it'll be you and a book, and a lot of hair-pulling.

Vectors and geometry in 3-space are important. Learn matrices, transformations, solving systems of linear equations, vectors, dot products, cross products, polynomials and their roots, planes, inequalities, gradients... all of this stuff is useful.

Know what the dot product and cross product are, conceptually. A dot product gives you how much two vectors point in the same direction. This can also be viewed as projecting one vector onto another (the dot product is then the length). Know how to get the magnitude of a vector (the norm), and about unit vectors (magnitude is 1 - also called 'normalized' vectors). Know what a surface normal is (a unit vector pointing straight out of the surface). Sit down and try to solve for the intersection between a ray (comprised of a vector and a point) and a sphere. Then get the 3d coordinates of the 0, 1, or 2 points at which they intersect (notice you get a quadratic equation - with 0, 1, or 2 answers - and that the sphere and ray can intersect in exactly 0, 1, or 2 places). Once you have that point in 3D space where the ray hits the sphere, find the normal of the sphere at that point (a unit vector). Find the light vector - the normalized (length 1) vector from the point of intersection to the light source. Then dot the surface normal with the light vector, and you'll know how bright the sphere is at that point. Set up an imaginary eyepoint in 3D space, set up a grid of pixels just in front of it, and cast rays out through each one of these pixels, seeing where it intersects the sphere (if it does) and plot the color at that pixel. If you have a bunch of spheres, plot the color of the one with the closest intersection.


Programming classes will teach you a lot of useful things. No matter what you're sitting there learning, and no matter how boring or lame it seems, stick with it. What will make you a good programmer is your ability to wield complex data structures for modeling physics or crazy algorithms for AI.

Though you might not see potential uses of the things when you use them, they will one day prove useful. Want to make a raytracer with reflections and shadows? You're going to need recursion. Want to depth-sort your polygons because a z-buffer is too expensive? You'll need to remember that merge-sort algorithm. Want to optimize the core of your game engine? You better remember your assembly class and how to cut the corners that high-level languages tend to go way, way around. It will all come in handy someday.

Also, if your major is computer science (or related), consider taking some graduate-level graphics courses as an undergrad (some colleges even have undergrad graphics programming courses). These can set you way ahead, and it is a good way to get your introduction to graphics programming. Just don't expect to be an expert after taking only a few courses and doing a few short labs (see next point).


Practice makes perfect. There is almost always a directly linear relationship between the amount of time one has invested in graphics programming, and how good of a graphics programmer one is. It seems like an obvious relationship, but there are a lot of people who expect to be able to just sit down and be a great graphics programmer. It's not that way. It just takes a hell of a long time. That's why you have to really, really, really want to do this.


One of the biggest hurdles in getting started is getting the video mode changed so you can play around with drawing pixels on the screen. This was easily done back in the days of BASIC. In Pascal, you needed a library, just as you do in C/C++ today. And now in Visual C++, if you want to use DirectDraw, you need to have a lot of free time and patience in getting the thing set up.

My suggestion: get yourself a small DOS-based C/C++ compiler and use the in-line assembly routines in the 'realtime' section of this web page, under the 'Graphics Programming FAQ' section.

You could also start with DJGPP, a freeware C/C++ compiler that has good built-in graphics libraries (as well as a ton of other stuff).

If you want to focus on 3D hardware acceleration, you should go with Microsoft's Visual Studio 6.0. If you're a student you can get this really cheap. It is a wonderful development environment and has an incredible debugger and the best online help I've ever seen - it includes full platform SDK support (DirectX help is built-in) and the entire standard C library, at your fingertips. Blows the doors off of those annoying man pages.


[ WARNING: these books are pretty out of date by now!! ]

Build yourself a good library. Any skilled trade requires reference material. Here are a few that I own that have really helped. However, I wouldn't do this until you're sure you're going to program graphics extensively, because it's going to cost an arm and a leg!

1. Michael Abrash's Graphics Programming Black Book

This book is 1200 pages of very good material. There is a lot of focus on speed and optimization. Though a lot of it is outdated - especially the assembly language tips which aim at the spanking-fast 486 - it teaches you the ideas behind why certain instructions are faster, how to cut corners, what a pipeline is, etc. It's a very good starting point for beginners. (Note that all the assembly is aimed at PC programmers). It also has tons of samples of assembly code for doing blindingly fast graphics operations, as well as a lot of discussion on topics like video hardware, BSP trees, rasterization, etc. The parts about the wonders of VGA video, the blinding speed of the 486, and the talk of Zen might make you laugh a bit. And a warning: it's expensive as hell.

2. The Personal Computer from the Inside Out: The Programmer's Guide to Low-Level PC Hardware and Software

As the title says, this is all about the Intel PC. If you want to know everything about the bus, data movement, registers, caches, memory, interrupts, instruction encoding, and assembly-language serial/parallel I/O, this is your baby. Content-wise, it is very up-to-date and to-the-point. Combine this with a knowledge of graphics algorithms and Intel's assembly language manuals (available from my links on my personal page) and you'll be doing some incredible stuff. (If you followed steps 1-4 above, of course =). This book's not too expensive, either.

3. Computer Graphics: Principles and Practice

This book is a great resource for graphics algorithms. However, you need to have a decent amount of experience doing 3D graphics to be able to use it. The great thing is that it covers EVERYTHING, from 2d line-drawing to the render pipeline, z-buffers, splines, lighting models, visible-surface algorithms, and advanced modeling and animation. I actually had this for a textbook in a graphics class at OSU (the Ohio State University). It comes in very handy. Be warned, though - it is expensive.

4. Jim Blinn's Corner: A Trip Down the Graphics Pipeline

Haven't read it - but it has been recommended to me a lot, and it's probably worthwhile. Jim Blinn pioneered an amazing amount of material in computer graphics. He had a column for a long time in a magazine that was called "Jim Blinn's Corner." I've heard about it a million times, even though I've never read it - but, apparently, it was some really good stuff. This book is a collection of some of those articles. I might pick up a copy soon.

5. Graphics Gems I through Graphics Gems V or so

I haven't read them yet - but they have been recommended to me as "essential" many a time (several times at Siggraph from various speakers, and through my friend Vince from a lot of the guys at EA - Electronic Arts). So I give these books the benefit of the doubt. There is a whole series of them. They are compilations of articles on tricky ways of writing fast graphics code. Appears to be aimed at game programmers.


The most important ingredient to being successful at graphics programming is dedication. Often you have to start it as a hobby, and take it as your undergrad focus for a Computer Science degree, AND have written some really awesome little demos, before a (good) company would hire you to do graphics programming work.

One thing I didn't mention is that there are a few annual programming conferences that are worthwhile. Check out the Game Developer's Conference held in March in San Jose, CA. Also, Siggraph is great, although it's a far more academic than GDC. It's held in a different city (in the U.S.) every year, in July/August.

Good luck!

[Back to Personal]

All programs, drawings, graphics and animations on this site are the pure
creation and copyright (c) 1993+ of Ryan M. Geiss. All rights are reserved.