The Fastest Sprite in the West (Lets talk VGA, Part 2)

What does one do when certain global events forces them to stay inside*? Well assembly language optimization of course! Today I’m going to tell you about how I made the slowest routine in the game 25% faster. This is about to get very technical so break out your assemblers and hang on to your hat.

*For those of you reading this from the future, this is because of the Coronavirus pandemic of 2020

The biggest bottleneck in the Chuck Jones: Space Cop of the Future is, as it is in most VGA era MS-DOS games, drawing sprites. The reasons for this are twofold. The first is that the CGA, EGA and VGA cards used in MS-DOS PCs did not contain any hardware to handle the drawing of sprites, like dedicates consoles of the time did, as a result the CPU needs to transfer every byte to the screen all by itself. The second reason is video memory wait states, essentially this means that video memory cannot be accessed by the CPU and the video hardware at the same time. Because of this the CPU needs to wait while the video hardware access memory before it can draw any more pixels, unfortunately the timing of these accesses are essentially random and varies between cards. Essentially this just means video memory is very slow, and how slow it is depends on the video card.

One way to speed up drawing sprites is to use repeated x86 string instructions, this way memory accesses can happen as quickly as possible. Unfortunately using these instructions is not always possible when sprites can be partially transparent, because a check must be done before plotting each pixel. There are several ways to speed up transparent sprites as well, the first being compiled sprites and the second being RLE sprites. Neither of these are really viable in CJ:SCotF, compiled sprites take way too much memory given that the game has many unique sprites and my use of planar graphics in Mode X make RLE sprites inefficient. So I’m essentially stuck with making the basic algorithm faster in assembly language. So lets try that!

Some C style code for drawing transparent sprites might look like this, while I don’t suggest anyone actually use this code, it illustrates the idea pretty well.

		char pixel = sprite[image_index];
		if(pixel != 0) //if the pixel is non transparent
			screen[screen_index] = pixel; //draw it
		//go to the next pixel
	//add the remaining distance to the end of the line
	screen_index += screen_diff;
	image_index += image_diff;

A basic assembly language implementation

So lets look at a pretty reasonable assembly implementation

; bx = num rows
; dx = num colums
; ds:si = sprite data
; es:di = screen data
rowLoop :
	mov cx, dx 	; reload pixel counter
	lodsb		; load 1 pixel
	test al, al
	jnz storePixel	; if the pixel != 0 then goto store
	inc di		; increment the screen pointer
	dec cx
	jz finishRow	; if no more pixels then goto end
	lodsb		; load 1 pixel
	test al, al
	jz skipPixel	; if the pixel != 0 then goto skip
	stosb		; store the pixel
	loop loadPixel	; if cx != 0 load next pixel
	add si, ss:lineDiff
	add di, ss:screenDiff
	dec bx
	jnz rowLoop	; if bx != 0 goto next row

This has a few advantages over the C version, the code can be arranged so that the skipPixel case falls through into the next iteration of the loop. This guarantees that only one branch is taken per pixel, this is especially good because on x86 processors branches that are not taken are much less expensive than branches that are. Additionally this version uses very compact string instructions such as lodsb & stosb which can be loaded very quickly. Now of course we can do better.

Unrolling loops

Lets apply a simple optimization, namely unrolling loops. This way we can do two pixels per loop instead of one so that we have fewer branches

; bx = num rows
; dx = num colums
; ds:si = sprite data
; es:di = screen data
rowLoop :
	mov cx, dx	; reload pixel counter
	shr cx, 1	; divide by two
	jz lastPixel	; if theres nothing left do the last pixel
	lodsw		; load 2 pixels
	test al, al
	jnz storePixel1 ; if the first pixel != 0 then store it
	inc di		; increment the screen pointer
	or al, ah	; al == 0, this sets al = ah & sets flags in one go
	jnz storePixel2	; if the second pixel != 0 then store it
	inc di		; increment the screen pointer
	dec cx
	jz lastPixel	; if no more pixels then goto end
	lodsw		; load 2 pixels
	test al, al
	jz skipPixel1   ; if the first pixel != 0 then skip it
	stosb		; store the first pixel
	test ah, ah
	jz skipPixel2	; if the first pixel != 0 then skip it
	mov al, ah
	stosb		; store the second pixel
	loop loadPixel
	test dl, 1	; if the number of pixels was even, otherwise do 1 more
	jz finishRow	; then jump to the end
	lodsb		; load the final pixel
	test al, al
	jz skipLast	; if the last pixel == 0 then skip it
	stosb		; store the last pixel
	dec di
	inc di		; increment the screen pointer
	add si, ss:lineDiff
	add di, ss:screenDiff
	dec bx
	jnz rowLoop	; if bx != 0 goto next row

How much better is this? Roughly ~22% better* then the standard assembly implementation above! That’s pretty good especially given that this code is a huge bottleneck in the game. I’ll admit that this isn’t a simple naive unroll, but it the unrolling allows us to use lodsw to load two pixels at a time which is a big win too.

However for even this code could be better. This code checks whether we have an even or odd number of pixels on each row, for tall and skinny sprites like characters this could be a significant waste of time given that we know whether the rows are even or odd outside of the row loop.

*timed on a 10 MHz 286 w/ VGA using the PIT counter for timing

Specialized routines

We can instead write 3 different routines. One for even widths, one for odd widths and one for a width of exactly one and then move these checks outside of the loop.

if(bytes_per_line == 1)
	doTransparentBlitOne(source.h, screenOffset, bitmapPtr, lineDiff, screenDiff);
else if(bytes_per_line & 1)
	doTransparentBlitOdd(source.h, screenOffset, bitmapPtr, bytes_per_line, lineDiff, screenDiff);
	doTransparentBlitEven(source.h, screenOffset, bitmapPtr, bytes_per_line, lineDiff, screenDiff);

The actual assembly code is a bit verbose so I won’t actually show it here. But with that optimization we get a further ~3% improvement on large sprites and even better with small sprites, definitely worth it!


Now I’m pretty sure that this could be faster, for one thing this version uses a lot of branches which is always bad, but right now I’ve down about all the optimizing I can handle. I actually did write a version without branching but it was actually slower than the initial implementation by about 30%! If anyone is interested I have the ‘final’ version of the code here, formatted as inline code for OpenWatcom C/C++. If anyone reading this comes up with some further improvements or alternative methods, I would be very interested to hear! Until next time, I promise you all one day, hopefully soon, I will actually finish this game…


Retro Hi-Fi Sci-Fi: Creating a unique style for Chuck Jones: Space Cop of the Future

Today let’s talk about style, specifically when you make a game that so obviously takes inspiration from classics in the genre which have their own strong aesthetic, how do you make sure it stays unique? Well, I decided that creating a strange mashup of things that I enjoy in an attempt to create a new style might be a good idea. The result is what I call “Retro Hi-Fi Sci-Fi”. Allow me to explain what that is:

When I first decided to make CJ: SCotF, I knew I wanted to make an adventure game and I knew I wanted to make it for DOS, but that was pretty much it. The first idea that I had was a sort of fractured fairy tale thing about a spoiled noble kid named Roland who gets robbed and has to make his way in a fantasy world. So I started programming and I got a lot done on graphics routines, scripting and path finding. The engine was starting to come together, but the story eluded me. But then, somehow I had an idea, just an image of a guy with a ridiculous mustache flying through space in a rocket powered El Camino. So I thought maybe I should make a game about that guy after I finish this fantasy game. That’s when I drew this picture:


Despite the limitations of my drawing ability (the perspective is more than a little wonky), it was this drawing of an orange ’70 El Camino SS with rocket boosters that convinced me to forget about the fantasy idea and roll with this crazy space game. Soon after, the pieces started falling in place, I came up with a story about a space detective.

The core of the Retro Hi-Fi Sci-Fi style is the fusion of 70s nostalgia through a 90s video game lens with classic Sci-Fi elements. I’ve tried to apply this to every aspect of the game, from the graphics to the music, to the story and characters. For example spacey Herbie Hancock tunes played on a Sega Genesis, blasting through the 8-track player of your muscle car would be supremely Retro Hi-Fi Sci-Fi. While I don’t have Herbie Hancock I’ll try my best.

A Marantz Stereo receiver, a great example of 70s Hi-Fi design. Simultaneously high tech and Classic

To apply this to character writing, its about making characters feel like they just walked out of a 70s cop movie, yet completely at home in a space station with walls finished like the front of a Marantz stereo receiver.

Walking into an inter-planetary discotheque complete with aliens

So I hope you can understand the idea of Retro Hi-Fi Sci-Fi; its a sorta Retro-Retro-Futuristic design and it ideally permeates everything. Well that’s the idea, we shall see how well I’ve applied it!

Please let me know if you have any comments or questions, I’ll see you next month!



Pixel Art Extravaganza!

Well, its March and the great Canadian winter has started to subside (for now), I figured it was as good a time as any to talk about Pixel Art! Specifically of the 256 color VGA variety. I’ve talked a little bit about this in the past but I think it deserves a dedicated article.

Most of the time I hear that letting a programmer make art will lead to disaster, but somehow I couldn’t deter myself. Despite being a programmer I was very lucky to grow up in a house where art appreciation and technique was instilled in me from a very young age, my mother is an oil painter and she taught me everything I know about light, shadow, perspective etc. All essential concepts for making 2D art.

The art of an adventure game is particularly important, great art in a game can even make up deficiencies in other areas. It’s one of the reasons I still love Sierra games despite them making me want to throw my computer out a window because Graham just got killed AGAIN with no warning and I have to reload my savegame! The style I decided to go with was something inspired by Monkey Island 1, specifically the VGA version. I thought it was a good compromise between the impressive but limited 16 Color EGA games like Space Quest III and Loom, and the more “painterly” hand drawn style of Monkey Island II and the Sierra games after Kings Quest V, that I don’t think would suit Chuck Jones: Space Cop of the Future.

Monkey Island VGA, I absolutely adore this style, with its bold palettes, wonky perspective and lots of dithering

This means that art would be drawn primarily in the computer pixel by pixel with a paint program. What paint program is that you ask? Well I actually use two, I usually start with GIMP because I’m very used to it and can work very quickly. However GIMP falls apart a bit when you start working with true 256 color VGA art. When I need to mess with palettes or draw dithered gradients I switch to Pro Motion NG. Pro Motion is and excellent program for working with genuine 8 bit indexed images that picks up where programs like Deluxe Paint left off in the 1990s.


In the picture above you can see both of these at work, I started by drawing the basic outline with GIMP, using a 3d Model I had prepared as reference for perspective (something I’ve always struggled with). The image was then brought into Pro Motion to do things best done in a true 8bit image editor, such as defining the 8bit palette and fill in the basic colors and shading, with liberal use of dithering. The image was brought back into GIMP where I worked on the fine details such as anti-aliasing around the text.

Some fantastic modern-style pixel art from Hyper Light Drifter

If you are unfamiliar with the technical aspects of old school pixel graphics you might be wondering why I keep stressing the fact that I’m talking “true” or “genuine” 8 bit graphics. The reason of course is that most modern pixel art games while often containing some great art don’t share any of the same limitations with as the games they try to emulate, they usually have a relatively low resolution but they’re not held to any specific limit and they tend to use whatever and as many colors as they please. I will also stress that this is a perfectly valid way of making game art and it is practiced by many artists much more talented than myself.

Landing on Orlokis
Even less than 256 colors!

CJ: SCotF on the other hand is a true 16bit game that runs natively on hardware from the 80s. The graphics are truly 8bit (8bits per pixel, 256 colors). When I make graphics for the game I’m limited by hardware constraints to a resolution of 320×240 and 256 colors, that’s it.

So now that I’ve given you an overview of what I’m working with and talked about drawing static backgrounds, lets talk about moving pictures, animations, the realm of the real Chuck Jones! Going with the whole 16bit DOS game thing, animations can’t have very many frames due to memory limitations. Although the timing of a frame is variable, most animations in CJ: SCotF run at around 8 jiffies per frame (1 jiffy = 1/60 seconds) which works out to the ridiculously low rate of 7 frames per second! While it seems like that would suck, I kinda like the result and its very much in line with the way things were in the early 1990s. Animations in the engine are simply just a list of frames with offsets and timing information, I usually make them by drawing layers in GIMP similar to the cels in traditional animation. These get exported to a custom image format and then I prepare a frame list kinda like this:

    chuck/left/chuck0.l4b -5 0 8 t
    chuck/right/chuck0.l4b -4 0 8 t
    chuck/left/chuck0.l4b -5 0 8 t
    chuck/left/chuck1.l4b -6 0 8 t
    chuck/left/chuck2.l4b -7 0 8 t
    chuck/left/chuck3.l4b -7 0 8 t
    chuck/left/chuck4.l4b 0 0 8 t

This gets converted to an internal engine representation and then we’re good to go. We are then treated with this walk cycle:

Well I suppose that’s all I have to say about that, if you wanna know more about adventure game art and pixel art in general (and I hope you do), I highly recommend this 2016 GDC talk by the legendary Mark Ferrari:


Revisiting the Chuck Machine, more on custom scripting languages

Earlier in the development of Chuck Jones: Space Cop of the Future I talked a bit about the scripting language that makes the game possible. I discussed how adopting a custom language and running it in a virtual machine could, if properly implemented, save memory and make writing game-play code much easier. As time goes on things change and ideas grow, luckily this idea has grown into pretty nice and very useful little language. So, lets talk about the language itself.

An older iteration of the Chuck-Machine Language

The last time I showed off the language on this blog, you could be forgiven for mistaking Chuck-Machine code for a bastardized dialect of FORTRAN. At this point the language has evolved into something a bit more elegant (when I say elegant I might mean closer to C):

procedure update
	var thisIsAVariable = 0

	var character = current_player

	var object = 5

	//we got loops
	while thisIsAVariable < 5
		//We got expressions
		var x = thisIsAVariable - 10 + get_object_x character

		thisIsAVariable += 1 //assignment add

	say_lines character
		"Wow this is a contrived example!"
		"I really wish I could use
		some real game code"
		"but then you might see some spoilers!"

	if character has object
		say_lines character "I have object 5!"

As you can see the most obvious change is that the begin/end type syntax has been replaced with a C-like curly brace style making the code much more readable. There are now proper arithmetic expressions and multiple operators can be used on one line. Perhaps the most important change however has been the specialized structures for writing dialog, much of the auxiliary code has been removed allowing be to write dialogue by just "writing dialogue". This very much reflects the design philosophy behind the Chuck-Machine language.

The machine language had a few very simple design goals:

  • Must be easy to read
  • Must be quick to write
  • Must elegantly express the concept associated with a point&click adventure game
  • Must be relatively easy to parse
  • Must correspond well to the generated byte-code

Additionally I defined what was definitely outside the scope of the language

  • Expressing complex mathematical ideas
  • Processing large sets of data
  • Writing standalone applications

The language is by no means flexible and really that’s the entire idea, it’s utility comes from it’s specificity. It is has no variable types (really one type) and about 80% of the builtin functionality is related to manipulating object in an adventure game.

Now that we have an idea of what the language looks like, lets talk about how it’s implemented. I won’t really talk about the interpreter because that’s pretty straightforward although interestingly probably contains enough GOTOs to make Edsger Dijkstra cry (I guarantee you this is not my normal practice, however I assure you that sometimes GOTO is indeed necessary however rarely).

The utility that compiles the scripts into bytecode however is more interesting. The utility called BASM was written in C++ and implemented in a way that no sane person would probably try. Had I been thinking sanely that day I would probably have used Yacc or Bison to generate a parser for my language potentially saving me a lot of work. Instead what I did was to create a “one pass compiler”, this is usually considered to be a bad idea. Luckily due to the simplicity of my language and virtual machine this did not turn out to be a big of an issue as it could have been. Another result of my language design decisions was how simple the compiler was able to be, the entire thing is only about 1,500 lines of C++ (keep in mind I use Allman formatting). Another bonus is how quick the compilation process is which any game-designer will know is great for fast iteration.

Fast BASM compiles make iteration quick

So I think I’ve said pretty much everything I wanted to on this subject, if you can’t already tell, this is an aspect of the game that I’m pretty proud of, I’ve always wanted to design my own programming language. I think I’ll leave you with one more example from the game itself demonstrating the “Movie Script” style dialogue syntax I’ve added:

procedure goto_room

	set_animation		current_player	10
	wait_for_animation	current_player
	set_animation		current_player	8

	var dr_klein = 29

		"Whoa, my head hurts ..."
		"Must've been quite a night"
		"Ahem ..."
		"Where the HELL did YOU come from!?"
		"Allow me to introduce myself"
		"I'm Dr. Klein,"
		"You've actually been out
		for quite a while"
		"You see ..."
		"You were cryogenically frozen"
		"So I'm in the future?"
		"Well not exactly ..."
		"Technically its the present now"
		"You're currently on a
		space station orbiting
		Excellon V"
		"Well anyway,"
		"We did unfreeze you for a reason"
		will explain everything"
		"You can find him in the
		GALACTIC POLICE headquarters
		on this station"
		"Well then,"
		"I'd better have a talk with him"




Reviewing a year in the Chuckiverse

Hello everyone,

Yes, I know I’m about a week late but it seems that’s just how I roll. Approximately a week ago we completed 2017, the first full year of development on Chuck Jones: Space Cop of the Future (Development began in 2016, just in case anyone was wondering). I figured I may as well give an update on what was done in 2017 and hopefully give an idea of where the game stands as of now.

some early notes

Back at the beginning of 2017 the game consisted of no more than a single room, some animations and an El Camino inside of a partially functional adventure game engine and a huge stack of design notes. The engine had a glitchy sprite system, an incomplete scripting language and could make some irritating noises on an adlib card.

Chuck Jones circa 2016

For the rest of the article, I won’t be able to cover everything, but I’ll go over a few things I found particularly interesting then try to sum of the current state of the game.

Firstly I wanna talk about the engine cause its pretty much done (finally). I did two things in 2017 that really made a difference: I started using version control and a bug tracker. Even for solo development and small projects these two things are incredibly important, the ability to keep track of all your changes and revert them if necessary is invaluable. Some new features added to engine were:

  • A full midi based music system with support for multiple classic sound cards
  • A memory manager to make the most of 640k of ram
  • Massive speed improvements on slower hardware like the 286
  • A Vastly improved scripting language
  • A much improved editor

Next lets take a look at the art. As you can hopefully see compared to the 2016 screenshot, I’ve learned a heck of a lot about making art for games.

Some more recent art


Additionally I’ve finally nailed down my process for music creation in the game and I’m really excited to keep working on new compositions.

So where do we stand then? Well the engine is feature complete, as in I cant think of anything else to add so I’m gonna call that 98%. About 75% of the planned locations have been created as pixel art and a few more consist as sketches. About half of the music has been written and the rest is coming along. Finally everyone probably wants to know when I’m gonna be done, well… I can’t tell you quite yet but I will say I hope not to be writing a second new year post for this game.


Chuck Jones on Android, or how the game will play in the 21st Century

Well as of a few days ago, Chuck Jones is now working on Android and iOS is in the works. Lets talk about how we got here.

People often ask me that since I’m writing a game for an ancient OS, how will they play it? A couple of weeks ago I began trying to tackle an important problem: How to package the game in a way that it can be played easily by people in the 21st Century. As the game runs on DOS natively, the obvious solution would be to do what GOG.com does and bundle DOSBox with an optimal configuration file. This is a pretty good solution but as good as DOSBox is, it has some issues. In my opinion DOSBox’s scaling is not very good, you will usually not get sharp pixels (not everyone’s preference but this is the way I want Chuck Jones to look), especially not on a modern 1080p monitor, this makes sense because most DOS games had non-square pixels which can’t usually be sharply scaled. Another issue is the lack of V-Sync which makes sense because most DOS games run at 75Hz and most modern Monitors refresh at 60Hz. One more thing needs to be addressed, DOSBox has no official port to mobile devices and the unofficial ones that exist are unsuitable for distributing my game.

So how did I tackle this? Easy. I forked DOSBox and modified the code to make a version that is designed specifically to run one game. Because Chuck Jones runs at 60Hz and has square pixels due to some tricks I described previously, I was able to add the features I wanted as well as making the experience of launching the game as smooth as possible. The average player will probably not realize that the game is not a native game for their platform (assuming the don’t recognize the DOSBox splash screen). In order to get the mobile version working I modified DOSBox to use the SDL2 Library which has better mobile support than SDL1.2 which DOSBox was using before. The way I improved the scaling was pretty simple. I first do a scale with no interpolation from the games native 320×240 resolution to the nearest integer multiple which is smaller than the display. For a 1080p display this is 1280×960 and from there it scales up to the monitor’s resolution bilinearly. I have been pretty happy with the results, its not quite a pixel perfect scale (unless you have a monitor with an integer multiple of the source such as 1280×1024, height doesn’t matter because it will letterbox).

As for the process of porting, it was not without trouble as the Android development tools are not the best (a slight understatement), especially for C/C++ which I needed to use to compile DOSBox but are my goto languages anyways. I used Visual Studio as my IDE for both Windows and Android which it doesn’t have perfect support for but I found it far less painful than Android Studio. Something that seems obvious first, converting between touch input to the mouse input in Chuck Jones, is not. A touchscreen tap happens at an absolute position while mice actually function by reading relative motion, the absolute position of the mouse is an illusion created by your OS (try moving your mouse to a point on your desk, move it away, then move it back, it should be in a different position on the screen now). Basically the code I wrote to translate taps only works if it knows were the game has the mouse initially and uses some math from there, since Chuck Jones always starts with the mouse at the center of the screen this is no problem. The next step is to add some buttons to the app to replace the keyboard keys in the PC version and then our next stop is iOS.

So now I have a cross platform solution to run the game on at least 6 operating systems (MS-DOS, Windows, Linux, Mac OS, Android and iOS) using a single binary, ensuring a consistent experience across devices. I’d say that’s enough to ensure that pretty much any 21st century player should be able to play Chuck Jones: Space Cop of the Future.

Extra bit for nerds:

My Fork of DOSBox on GitHub: https://github.com/pgrAm/DosBox-for-Chuck-Jones-Space-Cop-of-the-Future


Funky Future Music: Part 2

Jammin’ out

First things first, I know this post is a day late, I usually try to post on the last day of every month, but I figured people might be too busy with Halloween to read a gamedev blog post. So, I hope you had a good Halloween and lets get started. Last time I talked about the music in Chuck Jones: Space Cop of the Future, this time I’m gonna get technical and explain how I make that music. But before we start I’ll give you another sample from the game.

My ancient Drum Machine (with the worst LCD in history)

Right, so let’s get down to the nuts and bolts. Pretty much all the music in the game starts with me jamming out on several instruments in the analog realm, usually a guitar, bass or keyboard of some kind. When I discover an idea that I like I try to create a basic drum part for it, as I’m not a drummer/a very bad one, this usually involves messing around with my ancient drum machine until I come up with something I like. When I get to this stage I usually have a pretty good idea of what I wanna do with the song, so I head to the computer.

Drum Editing in Voyetra Sequencer Plus Gold

I usually start building the track in a program called Voyetra Sequencer Plus Gold for DOS, this is the software used by Bobby Prince for much of his excellent work for Id software. Using such an old program lets me hear things through a real Sound Blaster as I work. Once I lay down a drumbeat I start playing each part on a midi keyboard and recording it. Recently however I’ve been experimenting with using a guitar and some pitch to midi plugins, which is extremely helpful for some parts which don’t feel quite right with the keyboard. Usually I also check each part on an MT-32 as well as the Sound Blaster.

2017-11-01 (2)
Jumping ahead 20+ years

Once I get my basic tracks down it’s time to jump forward 20 years. I transfer a MIDI file exported from Voyetra via floppy disk, or LAN depending on the DOS machine I’m using, to a modern PC. Once on the modern PC I bring the file into my DAW (Reaper) and my performances are edited. I also use this opportunity to work out the final structure of the song. What I’m left with at the end is a type 0 MIDI file that can play back within the game.

Playback in the game can happen on Sound Blaster or through a MIDI interface to a device like an MT-32. On the Sound Blaster a special “.ibk” patch file is used to control the timbre of each instrument in the game (Thanks, Wohlstand for making this easy with OPL3BankEditor). On modern systems the game music is heard through a Sound Blaster emulator provided by the wonderful DOSBox project. All that’s left to do is sit back play the game and enjoy some righteous funk.

I hope you enjoyed this foray into the music of Chuck Jones: Space Cop of the Future. Hope to see you next time.

Home Brew Video Game Tools


Hey all,

You might be wondering what the glass of beer in the image above is all about, this a blog about game development right? Well specifically that is a glass of homebrew, something I began making around the same time I began work on Chuck Jones: Space Cop of the Future. Take a look at the list of projects for CJ: SCotF, notice how only one of them is labelled “Game”, well what are the other ones?


Well, when you make a game you need tools and in this case they need to be, just like the beer, home made. I figured I might go through all these tools and explain what they do and why I made them.

Adlib  Host

Those of you who follow me on Twitter or frequent the Vintage Computer Forum may already be aware of this one. It’s a tool to help me compose music for FM synth cards such as the Adlib and SoundBlaster by allowing a properly equipped DOS PC to behave as an external MIDI module, using the same sound engine as the game. This lets me make use of it’s FM synth capabilities in my modern sequencer so I can compose while hearing exactly what the final tune will sound like. This also allows me to use my MT32’s MIDI thru, send the module’s output into my mixer and be able to swap between FM and MT32 soundtracks just by adjusting a fader!

For those interested I have made this tool available for download.

Bytcode Assembler (aka BASM)

I’ve discussed this one in previous posts, but for those who are unfamiliar, it is the compiler (not assembler) for my custom scripting language. It is a command line tool that reads in text scripts and outputs binary byte-code to be interpreted by the game engine.

disBASM (Bytecode Dissasembler)

An example of a script and it’s disBASM output

This one is kinda cool, it mostly exists for the purpose of testing and debugging BASM and the interpreter. As you might imagine this program reads in a compiled script file and outputs a textual representation of the interpreter opcodes for it.


2018-01-31 (2)
Using the in-game editor while modifying a script

This is a collection of Perl scripts that perform a few functions to make editing the game a bit easier, for example the allow me while running the in game editor in DosBox to press a key combination and have the Chuck Machine script file for the selected game object open in Notepad++ on Windows and then run BASM to recompile the script after editing, I can then Alt+Tab back into DosBox where the object will be reloaded and I can continue editing with the modified script. Needless to say, this can save a ton of time.

Image Compressor

This little program is quite straightforward, it simply convert’s image files of various types into a custom .l4b file that is used by the game. These files are specially optimized for use in the game and are quite compact, utilizing the LZ4 compression algorithm. I’d like to thank Jim Leonard (trixter), for the idea for this one, as well as providing a fantastic well optimized decoding implementation, as it has cut the size of the game down considerably (great for a floppy disk release).

Sprite Converter

This tool is used for specifying animations for the engine. I went into a little detail about it last time, but the basic idea is that you create a list of frames and the tool spits out a binary .spr file which the engine uses to play animations.

Sysex Generator

I wrote this one for generating sysex commands for the MT32, I don’t really use it because I vastly overestimated the number of Sysex commands I would need to create. I ended up doing the entire thing in another tool (I think it was Midi-OX).

Well I hope I’ve given some insight into the less obvious bits about developing games. I’d like to thank everyone for reading, I’ve recently been getting quite a bit more traffic on this blog and I’m really glad that people are interested in the game and its development!

PS: For those of you who are noticing a lot of tech heavy posts, it’s because I sometimes have trouble coming up with creative post ideas. If anyone would like to, feel free to comment with suggestions for the next blog post or questions you’ve been wondering about and I’ll do my best to address them. If I get a lot of replies, perhaps I’ll do an FAQ.

Funky Future Music: Part 1

In my last post I mentioned that I’d soon be posting about the music in Chuck Jones: Space Cop of the Future. In case you hadn’t already guessed by the title this post is about music, specifically the funky kind. So lets begin.

When I first came up with the idea for this game I knew that the music had to be funk. Chuck is a cop that comes to the future from the 1970s, his image being crafted after classic crime films from that era, it made perfect sense that to accompany the game I would need some killer grooves. However being a DOS game, this funk would need to be synthesized by old school 90s era sound chips.

Funky 70s Music

So now that I’d decided on the music’s aesthetic I had to think about how I could achieve this. Being the kind of guy I am and being a bit of an amateur musician, I of course decided the best thing to do was write all the music myself, something I now admit I may have been initially ill prepared for. What I had to do at this point was surround myself with some groovalicious music. Specifically big my big influences were Herbie Hancock, Sly and the Family Stone, Emuir Deodato, Stevie Wonder, Steely Dan, Johnny Guitar Watson and Curtis Mayfield.

SuperFly Poster, amazing Curtis Mayfield Soundtrack

But lets go back for a second, earlier I mentioned that all this music had to come from 90s era sound chips. Just like classic DOS era games this leaves me with a few choices for sound, mainly: FM synthesis cards, the PC speaker or MIDI. If you are unfamiliar with 90s era PC games you may have heard FM synthesis in games for the Sega Genesis or perhaps via the classic Yamaha DX7 keyboard, the most popular option for PC was the sound blaster card. The PC speaker was a very limited device that was built into every PC and only makes beeps and boops. MIDI opened up your PC to use external sound modules such as the popular MT-32. All three main devices are supported by Chuck Jones: Space Cop of the Future and all music must be composed to sound reasonably good on all of them.

The YM3812, a classic FM synth chip

Of course because of this I would need to take a look at some classic game tracks too and of course no post would be complete without mentioning The Secret of Monkey Island, for which composer Michael Land made some truly excellent “Pirate Reggae”. Other games I drew upon include Battletoads and Double Dragon (Sega Genesis),  Ghouls n’ Ghosts (C64), Jill of the Jungle (DOS) and Police Quest II (DOS).

Now at this point you’re probably wondering what this all sounds like put together, as you’re probably also sick of my rambling by now I shall leave you with an excerpt of some music from the game:

%d bloggers like this: