DumbGame – A nostalgic look at DOS game development from scratch!

DumbGame is a video game I wrote in 2002 intended to serve as somewhat of a tutorial or map of how games were developed in years past, on the  80×86 architecture under DOS (Disk Operating System). Going through an old laptop hard-drive I recently rediscovered its source code, finally making an appearance on the Internet as intended, even more appropriate and nostalgic this many more years later.

Its name sake is due to the fact that the actual game play, graphics, levels etc. were minimally developed only to the extent needed to showcase the functionality of the game engine.

The game engine itself is of a skeleton development with only the platform game features most characteristic for the late’80 – early ’90 era. That being said it does have everything needed to design a full platform game around it, as well as illustrate how those features get implemented and ways to include additional ones.

The game was written in Turbo C for DOS. It accesses hardware directly as such in is not able to run on modern operating systems that invoke protected mode unless emulated. Luckily at the time of writing of this article there is still a version of Turbo C that has been ported for the MS Windows OS.

https://www.developerinsider.in/download-turbo-c-for-windows-7-8-8-1-and-windows-10-32-64-bit-full-screen/

The source code is split up into 8 different modules:

• DGG.C and DGG.H which houses the graphics handling functions.
• DGK.C with some keyboard setup functions.
• DGT.C hardware timer handling.
• DGF.C whose functions handle the loading and saving of level maps from files.
• DGS.C housing the sprite handling functions.
• DGTEXT.C setting up a custom bitmap font and functions to print characters and strings.
• DGMACHINE.C with all the functions the drive the behavior of the different game pieces (referred to as machines by convetion).
• DGM.C And finally DGM which stands for DG Main and houses the setup code and main game loop.

DGG.C and its associated header file make up a very basic video graphics library. We use BIOS interrupts to set the video mode to VGA (320×200 pixels) and setup the desired colored palette. In the specific video mode we are using the color palette is stored in the video DAC and screen pixels are mapped out in memory, starting at location A000 HEXADECIMAL. We accomplish reading and writing pixels by simply reading or writing the corresponding byte of memory. On older hardware such functions would be optimized by being written in inline assembly to aid performance, this is no issue here of course on account of us being in the future.

https://en.wikipedia.org/wiki/Mode_13h , here is some further info on the video mode specifics.

DGK.C houses only two functions, one that sets a higher key repeat rate for the keyboard and one that restores the default when the game exits. It is necessary to manipulate the key repeat rate because of the way the game handles keyboard input. This chosen method for keyboard handling is not as responsive as others and while used in some games it was not done so often. Having access to modern computing power we are able to slide by with it, I chose to do so since its ease of comprehension.

The purpose of the timer module(DGT.C) is to give us access to a hardware timer … this allows to have events in the game take place at specific time intervals regardless of the CPU speed on which the game runs. This is later illustrated by having one of the game machines unlinked from the hardware timer and its movement on screen is visibly much quicker than the other machines. More on this later.

The way we accomplish the machine timing is through the use of counters that count down until a specific event should take place. For the hardware linked timers that is accomplished by attaching an interrupt handling routine that decrements the timers every time it is evoked by the Programmable Interval Timer aka PIT.

We program the PIT with our desired timing and attach our handler to the interrupter it calls, of course we also have to make sure we execute whatever other handler were attached to it previously by other software and make sure we execute it at the appropriate time since we have programmed the intervals for out purposes.

This is done by the hander() function. The uppit() function programs the PIT with our desired timing. The normpit() restores the PIT interval on the channel we are using to default, here again I take a liberty with simply resetting the interval to the default settings upon exiting the game since we are running in an emulated environment it does not make a difference. However the appropriate way to handle this if running on an actual DOS platform would be to store the settings that the PIT was programmed at before we set ours and then restore those at game exit. In this way we are able to avoid causing conflicts and interfering with the behavior of other software that uses the PIT.

For more info on the PIT referee to this, https://wiki.osdev.org/Programmable_Interval_Timer

DGF.C has two extremely simple functions, one that writes out the array structure that holds our level map information from memory to a file and an other that does the opposite.

DGS.C provides the functions for sprite handling. Sprites are the pixmaps of images that make up the animations for our in game characters, and in the case of this game engine the level terrain and text characters.

flipspritey() is used to generate a mirror image of a sprite, since all sprites are defined in code in the form of arrays it is much easier just to make the computer do the work of generating the sprites for machines that move in both directions.

putsprite() and putblock() are very similar, they both put a sprite on the screen. Only difference in the two is how they access the memory where the sprite data is stored. The putblock() function using a pointer, this is simply due to the fact of how the in game text fonts are setup.

killsprite() is used for erasing a sprite off the screen, it does so in the easiest way by filling that specific block on screen with a chosen color, as such it can also be used to place blocks of any chosen color on screen.

All of these functions utilize the set_pix() function from DGG.C to set pixels on the display. This a very inefficient way to handle video graphics in general functions for sprite handling would use direct memory writes, inline assembly, even using “word move” instruction if available. Using the set_pix() function does make the code much more illustrative and intuitive to grasp, so we go with that,  and remember we are in the future so resources are abundant.

Text character pixmaps and font array are defined in DGTEXT.C, along with 3 functions one that initializes the array that stores the font, one for drawing a text character on screen and the third that uses the text character draw function to write out a character string to the display.

The putletter() function that draws a text character on screen is really just a wrapper. It calls the putblock() function that we defined in the sprite handling module and passes it the appropriate arguments.

DGMACHINE.C module contains all the functions responsible for the behavior of the in game characters. This would be a good time to discuss how a basic game engine operates.

A game engine in its essence is a collection of functions/methods/routines that implement the rules of behavior for all the active elements of game play. The active elements are generally referred to as “machines” as we stated previously.

Each of these machines (active game elements) has a function that handles its behavior, as well as data structure of some type that stores all relevant information for each instance of that specific machine type.

The main game loop calls on those “machine” behavior handling function, some functions that handle the passive elements and also ones that handle the user input.

Each run through of the main game loop has to handle user input, iterate through all instances of all machine types handling their behavior with the appropriate function, refresh any of the passive elements if needed and then render the collective graphics output of all game elements on the display.

While a game engine can be as simple as that, such as the one on display in this article, quite complex game systems and in game element behaviors can be derived by simply introducing more game machines and more instances of said machines. Just like in nature extremely complex behaviors and systems can arise form the interaction of elements that are individually guided by simple rules, however in totality the whole system’s behavior is anything but.

In the DGM.C module we put it all together. Levels are loaded, machines setup, etc.

After everything is initialized we enter the main loop and proceed to iterate through it until the game is quit.

A small note: If you look at the animated image of game play you can clearly see the some machines move much faster than others, specifically if you notice what is supposed to be “guy on scooter”. We mentioned this earlier when we talked about in game timers, as an example of CPU clock dependent game timer, this specific machine was deliberately untied from the PIT timer.

Early on in PC-XT and some 8bit architecture game development it was more common to see for games to use timers/delays that were dependent on the CPU running at a specific speed. As PCs evolved it was necessary to write code that was independent from CPU clock speed as the game could end up running on numerous different processors.

This was sometimes done by adding controls to the game that allowed to increase or decrease the delays on the fly to adjust for different clock speeds. A much more elegant solution is the one we presented here, by tying the delay counters to the PIT we are able to ensure events in game happen at regular scheduled intervals no matter the processor clock speed.