This article contains pixel art. For best results please use 100% browser zoom.

chopper258 is a port of Chopper Commando, a DOS game written by Mark Currie using Turbo Pascal in 1990.

Some thirty years later, in 2020, I've dusted off the old code and breathed some new life into it. I've ported it to C and made it work with SDL2, and it can now run natively in modern environments.

The canvas below shows a minute or so of gameplay from the new version.

The game can also be played on the web, thanks to emscripten.

Let's do a quick check to see if you can play.

Thanks to Mark Currie for granting me permission to publish this translation of his game.

In addition to publishing the source code, and playable version, playable version, I am also writing a series of articles to accompany the project, the first part of which is included below.

I have also made some animations and interactive parts that you can play around with, such as the palette picker later on in this piece.

Part 1

Background

I chose to revisit Chopper Commando for a few reasons.

One of the biggest ones is nostalgia. I remember enjoying playing this game as a child, on my PC and with others, and being surprised at some of the novel mechanics. I also remember having a good laugh.

This is the first game I played where you could leave a vehicle, run around and do things on foot, and then get back in and keep going. I thought that was so cool, and it was an early precursor to the sandbox games I enjoy today.

I have a soft spot for bedroom coded efforts like this, where the heart and soul of the game isn't obscured by many layers of polish. It's not too hard to imagine a 15-year old Mark Currie writing a game for himself on his 286, and getting a real kick out of doing so.

Games like this were pretty formative for me as a young aspiring games programmer. Unlike something like Super Mario, which seemed unreachable to me at the time, I could play this and start working out how to make something similar, even with the simple tools I had.

Project Scale

This was a bit smaller and more straightforward than my previous effort, Space Invaders In C. This project took around 3 months of calendar time, and about 200 hours were spent on it in total.

As the source code to the game was available, albeit in Pascal, not much reverse engineering was required. Most of the effort went into the translation to C, and building new code to provide workalikes for the Turbo Pascal API.

One of the last parts I worked on, the sound, also turned out to be one of the most difficult. The original game used PC speaker sound in a dynamic way, and I had to write a synthesizer for it. It was quite fiddly to get the timing right and make it sound like the original. More on that in part two.

The original code is around 5500 lines of Pascal, all of it game logic code. The new C version is around 5500 lines of game logic, 1500 lines of support code and 400 lines of comments.

Compared to the last project, there isn't too much behind the scenes unpublished code in this one. I wrote a few small pieces to aid translation, some scripts to build the font data, and some prototypes to help figure out the sound code.

I did end up writing a little bit of pascal code, mostly as temporary mods to the original game source to help me figure out what the original system was doing. More detail on compiling the old code is provided in a later piece.

Graphics

One of the very first things I did on the project was to figure out the framebuffer format for the original game, and start hacking to get it to display on a modern system.

The frame buffer is CGA, meaning it is 320 pixels wide, 200 lines high and has 2 bit paletted color, for a grand total of four possible colors on screen at any one time.

Below is a selection of screen shots from the game in all their CGA glory.

If you look carefully, even though each screen can only show four colors, you can see that there are more than four colors in total. This is due to palettes. In the CGA scheme, four base color palettes are available and each has a different arrangement of sixteen possible colors.

As an extra tweak, the first color in the palette (typically the background color), can be freely chosen out of the sixteen, giving slightly more flexibility. This means that there are sixteen variations of each of the four base palettes, giving sixty four palettes in total.

To play with the color combinations, click on the colored areas in the first panel below. You can pick a palette and background color, and the effect will be shown in the second panel, using one of the screenshots. Use prev and next to cycle to a different screenshot.

In the old system, the framebuffer and the palette settings are bits of memory that live on the graphics card and are twiddled by the game directly. In the new system, these reside in host memory, and must be converted into a modern texture format on the fly every frame for the GPU to use.

Given that there are only 64 possible palettes, a neat trick can be used to simplify and speed up the framebuffer conversion. Before the game starts running, every possible combination of palette, background color and input framebuffer byte (4 pixels at 2bpp) are iterated through, and the resulting 8 output bytes (4 pixels at 16bpp) are stored in a 16 * 4 * 256 entry lookup table. Converting the framebuffer each frame is then just a matter of iterating through each byte and performing a simple lookup and memcpy to stamp out four pixels at a time.

To be continued...

As mentioned earlier, the sound code was one of the hardest parts of the port. Part two explains why that was so, and the solution I used to solve it.

The canvas below shows a little preview.