Identical Games

Name:	Inertia Blast
Version:	0.90
Author:	Dennis Payne
License:	GPLv2 (mostly with some small CC-BY-SA 3.0)
Operating System:	Linux and Windows

Thrust

On the Commodore 64, players enjoyed the game Thrust by Jeremy Smith. I never owned the system nor played the game. When I first installed Linux I stumbled on a remake of Thrust. It was brutally difficult but I enjoyed the game. At the time I ran it under svgalib, an old console graphic system which required root access. Recently I decided to track down this old game.

The version I played advanced a little since I last looked at it. X windows support was added but only with pseudo color mode. Pseudo color mode supported systems that could only support 256 colors at a time. Programs could ask for colors but depending on what was available they might not get it. Games would take control of the entire palette but only when the window was active. Any other windows on the screen would have weird colors during this time.

Needless to say it is not generally used now. The programmer also added support for GGI and DirectX. Neither of these were much help. To make the game playable again, it needed some work.

SDL2

SDL2 is my general solution for graphics, input, and sound for games. There are other options but I have found SDL2 to be the best choice in the past. The thrust clone specified a graphics, keyboard and sound interface. Sound was initially ignored.

My game Troll Bridge originally supported svgalib. It was limited to 256 color as well. For the SDL2 implementation. I copied the svgalib graphics code and replaced it with the Troll Bridge implementation. The display was setup for 32 bit color. A second surface was created with 256 color. All drawing would be done to this surface and then copied to the true display. It's not particularly efficient but works.

The keyboard routines proved a little harder to decipher. The game operates in two modes, single key mode and multiple keys mode. For the title menu, pause screen and similar screens, it works in single key mode. You are getting a single key press at a time and operating on it. The game uses multiple keys mode to get rotation keys, thrust and other keys. Multiple key mode had the mind boggling named getonemultiplekey() function. The key configuration screen used this function to get the key to replace the default key for an action.

Once understood replacing the keyboard didn't take long. There are two functions which required additional understanding, keystring() and keycode(). These functions converted scancodes to strings and vice versa. The key configuration used them to write a configuration file. SDL2 had functions to do this but I expected to have to transform the scancodes into the names used by the game. It turned out each keyboard implementation keeps it's own set of key bindings so there is no common name used by all implementations.

SDL2_mixer allowed a quick implementation of sound. The only tricky part was that the sound files where snd files which SDL2 didn't load. The existing sound implementation played them directly on the audio device. I created Mix_Chunk structures with the audio data and played them. They sounded correct.

Building

The game played like I remembered but building was a problem. For my initial development I hacked the autoconf generated makefiles to build the SDL2 version. I tried to add SDL2 to the autoconf implementation but could not get it working. Telling people to modify the generated makefiles didn't seem like a friendly option. Instead I created a cmake implementation which would only build the SDL2 version.

The only problem was that autoconf generated the config.h file. To build the program you needed to run configure so that config.h was generated and then use cmake. Eventually I decided to not maintain the old graphic implementations and included the config.h in the source code.

Inertia Blast

Before going further I needed to resolve a simple issue. This clone uses the name of the original game. While that might be helpful to explain the game to old players, it should have it's own identity and not trade on someone else's brand. Controlling your movement is so important I decided to use inertia in the name. Thrust has action to it so I settled on Inertia Blast.

New Images

When looking for this Thrust remake. I found Thrust 30. It too was a Thrust remake but completely replaced the graphics. It ran on mobile phones and the web. The code was open source but the levels were not.

I loved the look but preferred a local application to a web game. Web sites disappear without warning. I decided to try and replace the graphics. I discovered that the title screen seemed to be copied from a version of Thrust and possibly the story text. To avoid copyright violation, I needed to replace those.

Rather than spend money commissioning artwork, I built a Lego version of a ship similar to Thrust 30's ship. Unfortunately I didn't have the pieces in the right color. I'd planned to order them but ended up building it digitally and liking the result. Some modifications were made to reduce the obvious Lego look. For the energy pod, the Lego pieces overlap in way that are physically impossible.

Inertia Blast compiled all the images into the executable. There were several helper programs to convert the files to C files. Most images were bmp files but the title screen was in ppm format. The ppm file included a palette in the C file while the bmp files did not. This meant the ship in game could be yellow despite the white color in the bmp file. The title screen simply overwrote some of the palette.

I didn't completely understand the palette handling when adding the new title screen. I hardcoded the addition of the title screens palette in the SDL2 graphics implementation. Replacing the ship image did the same but I needed to fix the palette handling. I converted all the images to ppm. Now I had a palette with everything. The total number of colors used in the original game was fifty one. I had space to load each image's palette into a 256 color palette.

The game completely broke. Initially the ship blew up immediately. When I fixed that, you couldn't shoot anything but they could still kill you even when your shield was active. Even the background stars collided with the ship. What I hadn't realized was that collision detection was baked into the palette. The shield protects against colors higher than the shield color. Since I loaded the bullet palette first, it no longer stopped bullets.

I didn't want the collision detection dependent on the order of loading the palette. It needed to designed in a way that images can be easily replaced. The solution ended up being a collision value for every palette entry. When loading the backgrounds you can run into, the non black colors would have a collision value of two. Things you can destroy would have a value of four and bullet were one. Shields protected against anything below two.

New Features

With the ability to add new images, I added a disabled power plant image. Inertia Blast isn't designed to change an image. The power plant blinks when it is exploding but otherwise images are only removed. The disabled power plant needed to be drawn when first hit and restored to the working image when repaired.

Early on I started collecting statistics in the game. Tracking included overall counts, best runs in any game, and the current game. Achievements use this data. Right now there are only two achievements but the data allows for more to be easily added.

More animations will likely be added in the future. Fire from the engine when using the engines would be a nice addition. Overall I'm happy to be able to play the game again. I've even managed to get further.