24 years of game programming: thrills, chills and spills: part 1

Originally I was thinking about calling this article 24 years of game programming: observations and lessons learned. Somehow the title seemed much too stuffy for an entry about something I’ve loved so much over the years.

In this three part series I trace my 24 years of game programming. From machine language in 1982, Pascal in 1987, C in 1992, C++ in 1995, using “high level API’s” like OpenGL in 97, catching the pattern craze in ’98, the component mantra in 99, coding for 3 consoles at once in 2000, moving into Java, C#, and javascript on the top of C++ in the 21st century. And more!

Let’s go back to 1982:

This is where it all began for me. I had received my first computer a Vic-20 and dreamed of everything I could do with it. William Shatner had advertised it as a gaming system and a computer too (and we all know he has integrity from the whole priceline fiasco). I remember writing my first basic program for it from the thin manual that came with it. An animated bird that used character graphics to flap it’s wings and fly around the screen. I was mesmerized!

I quickly learned the machine inside and out, bought the Vic-20 Programmer’s Reference Guide, hung the schematic of the machine on my wall and went to work. Very quickly I realized that a 1 mhz machine with 5k of ram was going to take some heavy tricks to create games for. So I learned 6502 machine language to really pull the stops out. An 8 bit processor with an X, Y and Accumulator that could add and subtract any 8 bit value! X and Y could only increment and decrement. And of course when the numbers were larger than 255 a little juggling was required.

Very soon the Commodore 64 came out and I immediately upgraded. Programmable sprites, a SID chip for sound, 64k of ram (with 16k bank switched under rom that held Bill’s basic and the “OS”). Now we were playing with power. I wrote more than a few games for the Commodore 64 as a hobbiest in straight machine code. An Olympic games type clone, a chess game that worked with the 300 baud modem, a utility to dump on screen graphics to the printer, some arcade variations, a sprite editor.
These were the truly brass tacks years. 6502 machine language mixed with little bits of bootstrap basic was hardcore by any standards. Jumping to subroutines was something you couldn’t take lightly and the “hardware” stack was only 512 bytes long. It was strictly for keeping the return address from subroutine calls. I was firmly convinced games required maximum power and could only be written in machine language. I was pretty convinced this fact would never change.

I was of course wrong.

Fast forward to 1987:

The IBM PC/XT was starting to show promise and a friend introduced me to Turbo Pascal on it. 4.77 megahertz! 640k of ram. Sure my machine was an XT and only capable of CGA graphics (and character mode graphics – not even programmable at that). But Turbo Pascal was my first true compiler. It was actually possible to write a significant chunk of many games in high level code. Sure low-level interrupt stuff was often in assembly. We spent many, many all nighters coding games and often ignoring our girlfriends. But they couldn’t code:) I slowly got used to the fact that passing variables on the stack was a useful enough concept that it was worth the performance hit it sometimes had on games. We are talking about functions passing parameters on the stack! But this was “non-trivial” and took cycles. Things were still so tight that every cycle mattered.

Fast forward to 1992:

I got my first 386 20 mhz clone with 4 meg of memory and an 80 meg hard drive. I quickly bought a soundblaster card for it. Before long I was coding games in MCGA 320×200 256 color graphics mode. I learned everything I could about palette manipulation and palette color theory. I was coding in C by this time as well 8086 assembly of course. You could actually inline your assembly right there with the C code. It was awesome. I wrote a sprite compiler that would literally turn all the data into straight machine code so it didn’t have to loop and check for key colors. It used a triple buffer, dirty rect system to update the screen as efficiently as possible.

I learned Autodesk animator inside and out and spent hundreds of hours working on a sprite editor with bucket fills, circles, lines and palette manipulation functions as well as animation capability. I was in heaven. I recruited some good friends to do graphics for me and created a number of demos to show off the library.

I still hand-optimized everything and didn’t trust the compilers at all. A C compiler may not use a bit shift for an integer multiplication. The horror!

I made sure and learned all I could about fixed point numbers. At this point floats were still done in software and slower than hell. Since C didn’t support operator overloading the code looked pretty clunky. But it didn’t matter. 320×200 256 color mode was fast – really fast. And I was learning all I could from Abrash books about mode 13 hex that allowed the full 256k of graphics memory to be utilized. At the time the PC was still back switching 64k into it’s memory map. And don’t even get me started on 80×86 segment offset addressing!

I ended up releasing all my code as shareware and learning the ins and outs of shareware distribution mechanisms. I remember printing labels for 5 1/4 and 3 1/2 disks and mailing them off to shareware distribution hubs. This was before the internet took off of course and everything was BBS based.

1995 was right around the corner and soon I would find myself working at Legend Entertainment on Star Control 3 – my first commercial game product.

Part 2 cracks the lid open on my game industry years.

9 thoughts on “24 years of game programming: thrills, chills and spills: part 1

  1. Matt Barton

    Very interesting reading! It’s really fascinating how so many coders cut their teeth learning machine language, then gradually moved to higher-level languages as the hardware got better (and no doubt more difficult to program “close to the machine.”) I’ve been slowly learning C++ over the years, but I’m curious about how important assembly and machine language are in modern game development. I’m guessing it’s mostly useful for making drivers?

    I’m also curious how your shareware years turned out. Did other programmers write in with tips for refining or extending the code you released?

  2. Steve Riley Post author


    Yes, especially game coders often times get knee deep in assembly at some point. I wrote assembly often in the 80’s and early 90’s. In the late 90’s I was merely inspecting compiler generated assembly for optimization purposes (and then tweaking C++ code) and in this century don’t look at machine code at all – except in the case of the PS2 – but that shouldn’t be the case. These days dealing with assembly is often seen as a sign of a bad compiler unless you are writing a compiler or very special device driver.

    These days I would ignore assembly – you won’t end up needing to use it. C++ is still integral to game programming just because of the very explicit control you can exercise with it – when you really need it.

    Most modern games have a very small assembly core, with a C++ infrastructure and a scripting language on the very top. .Net and Java are actually doing amazing things with performance – but in my gut I’m still a little old school in that respect.

    The most important thing is optimizing your high level algorithms. These days counting CPU cycles doesn’t do you much good unless you are writing device drivers or low level graphic API’s.

    My shareware years were quite a lot of fun. I had a few handfuls of customers, but suffice it to say I was selling very niche development tools. It was my consulting jobs that kept the bills paid at the time:)

  3. James

    Nice article. I think you meant your 386 had a 80 meg HDD!

  4. Steve Riley Post author


    Yep – the orders of magnitude changes still boggle the mind.

  5. Philippe

    Oh the memories! I remember the 8086 and 386 old times where every bits of ASM code had to be carefully weighted :)
    Now honestly I don’t want to hear about malloc and the like anymore…

  6. Steve Riley Post author


    I couldn’t agree more. The memories are great but I’m glad that assembly and many of the aspects of manual memory management are a thing of the past. Working with garbage collected languages and concentrating on high level problems just makes more sense.

  7. Peter

    Very interesting I look forward to the rest of the article. Only a couple of comments. You mentioned about William Shatner’s ad for the Vic 20. You kind of intimated that his integrety wasn’t as good as it could have been with something about the “Priceline Fiasco”. What do you mean by this?

    Aslo a minor typo in the first sentence of the first paragraph of Fast forward to 1987:

    “The IBM PC/XT was starting to show promise and a friend introduced my to Turbo Pascal on it.”

  8. Steve Riley Post author


    Thanks for the comment. A few years back when Priceline wasn’t doing so well William Shatner claimed he had never actually used Priceline for anything – he had been representing them for a number of years in commercials though:)

    I fixed up that edit as well – thank you:)

  9. Buu

    Oh the memories! I too started out on a Vic 20 and oddly enough with that same damned flapping character bird. Hell, I didn’t even have a cassette system to attach so I had the thing memorized. Of course I was only 7 or 8 at the time, wasn’t like I could just go and buy one (nor my parents, they were baffled by the machine). :)

    The passing the arguments on the stack thing brought me back as well. It made me realize how much crap we take for granted with compilers these days.

    The next time the children at work complain about how difficult something is, I’ll point them to this post.


Leave a Reply