|Previous||Table of Contents||Next|
I got my start programming on Apple II computers at school, and almost all of my early work was on the Apple platform. After graduating, it quickly became obvious that I was going to have trouble paying my rent working in the Apple II market in the late eighties, so I was forced to make a very rapid move into the Intel PC environment.
What I was able to pick up over several years on the Apple, I needed to learn in the space of a few months on the PC.
The biggest benefit to me of actually making money as a programmer was the ability to buy all the books and magazines I wanted. I bought a lot. I was in territory that I new almost nothing about, so I read everything that I could get my hands on. Feature articles, editorials, even advertisements held information for me to assimilate.
John Romero clued me in early to the articles by Michael Abrash. The good stuff. Graphics hardware. Code optimization. Knowledge and wisdom for the aspiring developer. They were even fun to read. For a long time, my personal quest was to find a copy of Michaels first book, Zen of Assembly Language. I looked in every bookstore I visited, but I never did find it. I made do with the articles I could dig up.
I learned the dark secrets of the EGA video controller there, and developed a few neat tricks of my own. Some of those tricks became the basis for the Commander Keen series of games, which launched id Software.
A year or two later, after Wolfenstein-3D, I bumped into Michael (in a virtual sense) for the first time. I was looking around on M&T Online, a BBS run by the Dr. Dobbs publishers before the Internet explosion, when I saw some posts from the man himself. We traded email, and for a couple months we played tag-team gurus on the graphics forum before Dooms development took over my life.
A friend of Michaels at his new job put us back in touch with each other after Doom began to make its impact, and I finally got a chance to meet up with him in person.
I talked myself hoarse that day, explaining all the ins and outs of Doom to Michael and an interested group of his coworkers. Every few days afterwards, I would get an email from Michael asking for an elaboration on one of my points, or discussing an aspect of the future of graphics.
Eventually, I popped the questionI offered him a job at id. Just think: no reporting to anyone, an opportunity to code all day, starting with a clean sheet of paper. A chance to do the right thing as a programmer. It didnt work. I kept at it though, and about a year later I finally convinced him to come down and take a look at id. I was working on Quake.
Going from Doom to Quake was a tremendous step. I knew where I wanted to end up, but I wasnt at all clear what the steps were to get there. I was trying a huge number of approaches, and even the failures were teaching me a lot. My enthusiasm must have been contagious, because he took the job.
Much heroic programming ensued. Several hundred thousand lines of code were written. And rewritten. And rewritten. And rewritten.
In hindsight, I have plenty of regrets about various aspects of Quake, but it is a rare person that doesnt freely acknowledge the technical triumph of it. We nailed it. Sure, a year from now I will have probably found a new perspective that will make me cringe at the clunkiness of some part of Quake, but at the moment it still looks pretty damn good to me.
I was very happy to have Michael describe much of the Quake technology in his ongoing magazine articles. We learned a lot, and I hope we managed to teach a bit.
When a non-programmer hears about Michaels articles or the source code I have released, I usually get a stunned WTF would you do that for??? look.
They dont get it.
Programming is not a zero-sum game. Teaching something to a fellow programmer doesnt take it away from you. Im happy to share what I can, because Im in it for the love of programming. The Ferraris are just gravy, honest!
This book contains many of the original articles that helped launch my programming career. I hope my contribution to the contents of the later articles can provide similar stepping stones for others.
|Previous||Table of Contents||Next|