In 2004, though I didn’t realize it at the time, I finally achieved one of my childhood goals by writing a primitive 2D game engine/library in assembly and C. My resources were The White Book, LaMothe’s Black Art and Lafore’s Assembly Language Primer. It was incomplete and I never actually made any real games, so it was hard to see it as the victory it was.
I was able to prove to myself that I could teach myself to do it and that it wasn’t any harder, really, than the other types of development I’d taught myself to do for a living - just different.
Here are some of the programs I built as I learned, starting with simple technology tests written in C with occasional assembly (mostly for managing video modes, as I recall).
Palette test
This is about the point where things started to get really interesting in my pursuit of 16-bit DOS graphics and game development. I added a set of palette modification functions to my "assembly" library. Then I wrote this program to test them out.
The results, after many hours of coding, were quite gratifying. This palette is displayed in video mode 13h.

Palette shifting 1

Palette shifting 2

Palette shifting 3

Drawing test
This is a program designed to create a pretty graphic. This was also the first program to use my ass_flopScreen() function in the assembly library.
(All functions with an ass_
prefix can be found in the assembly.c and header files. They were all later renamed with a gu_
prefix in my Gameutil library.)
The colorful results:

My character set
I became quickly aware, as I developed my DOS graphic programs, that I was going to need to create my own character set to be displayed in video mode 13h.
I drew each character, pixel-by-pixel, and then translated them into a hex number.

Blinking bear sprite
This was my first program that used a bitmap sprite that could switch between cells to create a simple animation. Each cell is a separate .bmp file. They are labeled bear000.bmp-bear002.bmp so that the program can find them.

Evil flying bison sprite
This program was a combination test. First, I have an animated sprite (a bison photograph I took while in Yellowstone Nat’l Park). It’s eyes can glow. Then, I animate the sprite (eyes flashing) moving up and off the screen. Elementary, but the next logical step in the process of creating something approaching a game.
First it’s just a bison on the road:

But then the evil spirit rises as the eyes flash red. What is happening!?

BView - a bitmap viewer with various image manipulation effects
s program is a relatively simple bitmap file viewer. To use it, simply enter the filename of the bitmap you wish to view as a command line parameter, like so:
bview goat.bmp
Once the image is displayed, you have a number of keypress options as outlined here:
m - display the menu (showing the key shortcuts) g - converts the image palette to greyscale f - flips the image vertically i - displays important image information p - shows a graphical display of the image's palette Esc - the escape key exits the viewer
All of these options are toggles, meaning that the options can be toggled on or off by pressing the associated key.
One strange thing I found out about bitmaps is that the colors are not stored as RGB values, but as RBG! This really threw me off until I figured it out. The specification document I was using made no mention of this strange bitmap quirk.
A menu is displayed at the top using my character set:

The image flipped:

An information panel:

Bitmap image palette:

It can convert to greyscale!:

Converted to greyscale, flipped, and displayng the palette:

BMP to POV-Ray
POV-Ray, The Persistance of Vision Raytracer is one of my favorite programs. It’s a text-based 3d raytracing renderer. In addition to being a lot of fun to play with, Pov-Ray’s easy to learn and understand text format makes it very useful as a renderer for mathematical and scientific output.
My program takes a bitmap image and turns it into a POV-Ray .pov file. The pixels in the bitmap are turned into a plane of spheres which can be rendered in a variety of ways. Here are the command line options:
bmp2pov [file] [plane x,y,z] [x] [y] [z] [sphere size] [sphere offset] [palette offset]
Example: bmp2pov cheese.bmp x 20 30 10 3 2 1
This would use the file named cheese
, display the image as a plane on the x axis, starting at x position 20, y position 20, and z position 10, the spheres (each representing one pixel) would be a POV-Ray size of 3, would be spaced by 2 POV-Ray units, and the palette would be created with the palette numbering starting at 1.
The program will output a .pov file which you can modify to your heart’s content or merge with an existing Pov-Ray file to create a scene.
Here is my very first first 4px (yes, just four pixels!) bitmap test image:

Arnold as the Terminator rendered as a horizontal plane of spheres - note the almost elven ear:

Creature "game"
The creature game is very simple. You control the movements of a small, strange animal using the arrow keys on the keyboard. The creature becomes frightened when you move him off the ground, but can be calmed, by moving him under the carpet where he feels safer.
This program was the next logical step towards having a real, working game. It utilized pretty much all of the features I had created in my new Gameutil library and forced me to create a number of new ones. I even had to write my own keyboard interrupt driver. At this point, I was really starting to realize why people don’t make DOS games anymore.
Here is the creature hiding under the carpet:

The creature appears when it’s moved out from under the carpet.

Oh no, the poor creature is off the ground and has become frightened!

The Space Game
The Space Game is not finished. For this reason, it’s not much of a game. All you can do is use the four arrow keys on your keyboard to move the ship left, right, up, and down. There are three scrolling, seamless backgrounds that move with you to simulate paralax movement.
You could also fire a projectile of some sort, which would fly in the direction you aimed and would then disappear off the screen.
I also started on enemy sprites, but never got as far as making them move.
Here we are flying our spacecraft to the right:

Now we fly to the left:

This was/is my final stab at DOS game programming. I never meant to create anything big in the DOS environment, my real goal being the creation of OpenGL/DirectX games.
But ever since I got my first PC, I had always dreamed of learning how to do all of this stuff the hard/old way. I fully satisfied my curiosity.