Archive for the 'Bob’s Fury' Category


Huffman Coding

Quite some time ago I did a short post about a compression technique called run-length encoding (or RLE), that was a commonly used compression method for graphic and level data. At the time I wrote and implemented it for the graphics and level data for my home-brew game Bobs Fury with quite the success, significantly reducing the disk space required for the base game.

I do however have some files left, which are largely just ASCII text, that don’t compress well or at all using that technique. I’d like to make them smaller, and of course harder to read as they contain story text, not that my game has a brilliant story, but you get the idea. Step in an encoding technique called Huffman coding.

Essentially the encoding algorithm encodes symbols as a variable length stream of bits. The most frequently used symbols are represented by shorter bit streams, whilst the least used have longer ones. Normally in a computer each symbol would be encoded as a fixed number of bits, such as say 8-bit or 16, so this results (hopefully) in shorter encodings for most symbols, and longer ones only for the rarely used ones.

The tricky part is creating the Huffman tree, which is basically a code-book representing how each symbol is encoded or decoded. Here is a quick tutorial on how they are created, which will also give you a feel for how the encoding works. It’s also commonly known as a dictionary, or code book.

A fixed tree can be used for everything, but would not do the best job for every set of data being compressed. So typically a tree is created and stored along with the encoded data to achieve the best compression possible. This of course does add some overhead, which could be a problem if the resulting encoding isn’t much shorter than the original.

Huffman coding typically works poorly when the symbols all appear in the text at roughly the same frequency. The worst case being everything with exactly the same frequency. Notably it won’t produce an encoding that is longer than the original data, although with the overhead of storing the tree, you could end up with a larger data file. In practise this rarely happens.

Other data such as English text stored in ASCII actually compresses quite well. As usually not all the 255 characters are used, most encodings will be shorter than 8 bits per symbol. Also because natural language uses some letters more than others the average encoding length for all the symbols will be shorter.

Huffman coding was actually invented quite some time ago (1951) by David Huffman, well before it came into common use. Check out the Wikipedia page for more information. It’s a part of many commonly used compression programs and formats such a Zip and Bzip. Older 8-bit machines typically weren’t powerful enough, so it wasn’t commonly used until more powerful machines with more memory became available.

It took me much longer than usual to write this post primarily because I began the process of writing an encoder and decoder, but because of the complexity, it’s taken up much more time than I expected. Currently I have just finished the encoder, but have yet to test it. I had hoped to get the code running first, but that will have to wait.


Improving Joystick support for Bob’s Fury

Some of the hardware support within Bob’s Fury has been far from ideal, the joystick/game pad being one such device. I had only added support for a simple 2 button joystick, as that’s all I had when I first wrote the code a long time ago. It proved to be inadequate as there just simply wasn’t enough buttons to support all the functions in game, and you couldn’t choose what the buttons do.

Old Joystick Configuration

Old Joystick Configuration

So with the aid of a real machine and a Gravis game pad I worked out how the basic 4 button devices work. It turns out they aren’t much different. I had originally coded my interface to expect two joysticks, each with 2 axis and 2 buttons. It turns out that the buttons on the second joystick correspond to the 3rd and 4th buttons on the Gravis game pad, which means it was fairly simply to allow such a device to support 4 buttons with a minimal effort. I re-wrote the joystick hardware code to be a single joystick with 4 buttons and axis which should support most devices.

New Configuration Screen

New Configuration Screen

Once I got the joystick code re-worked I didn’t want to give fixed functions to the buttons, so I had to recode the configuration interface to allow changing what the buttons do, which funnily enough took longer to get right than the hardware side of things. After some testing in Dosbox I’m pretty happy with the result. I still need to test on some real hardware to make sure everything works, and I need to test a two button joystick to ensure that still works as well. I’ll update the download once I’ve tested it on real hardware.


Download for Bob’s fury

This week, after much time thinking about it, I decided I’d finally offer my old school platform game, Bob’s Fury for download. I originally wrote it in Qbasic back when I was 14 with the help of my younger brother who did some of the graphics, levels and helped play test it. The idea for making my own platformer had grown out of playing two of my then favourite games, Xargon and Hocus Pocus.

VGA Screenshot

VGA Screenshot

I originally had much larger plans for it, I had wanted to make water levels and puzzles like those in Xargon and run and gun sections like those in Hocus Pocus. At this stage I was still using gwbasic and I found that it was difficult to store enough graphics and tile information for one screen, it seemed like I wasn’t going to be able to build anything at all when I discovered Qbasic on the school computers.

Qbasic had many advantages, it supports a better graphics mode which allowed 256 colours at 320×200, then a common resolution for most PC games. The interpreter also had roughly twice the memory available to it which allowed me to use many sprites and get two screens per level. It took me roughly a year to build the engine and most of the levels. It was still quite limited in many aspects and didn’t live up to the original dream, but it was still a significant achievement.

Later in high school I had a computer studies teacher who did a bit of programming themselves. I know it seems odd, but not that many teachers of computer studies could actually program in those days. Anyway I was lucky enough that he gave me a copy of Borland Turbo Pascal 6.0, which was to be the first compiler I’d get to use. It was a bit of a learning curve, but I managed to learn pascal much quicker than either basic. I decided I wanted to port Bob’s fury as Pascal was a much faster language and wouldn’t be as limited as Qbasic.

EGA Screenshot

EGA Screenshot

I had a few problems however when I learned the graphics library. Firstly I hadn’t encountered pointers before, and they were required for bit mapped graphics. So I experimented with some simple vector graphics at first. Also Pascal didn’t have any support built-in for the graphics modes I wanted to use. So I put off making a port until I could learn more about the language.

Shortly after I went to University and got internet access I was able to solve some of these problems. I practised and learned how to use pointers in general and I found files that provided support for the graphics modes I was after. By 1999 I had built much of the tools and libraries for graphics and a few ancillary libraries needed. I’ve been working on this port sporadically since then.

I’ve been reluctant to release it for a few reasons. The first one being it’s quite unfinished. I haven’t really made enough new levels, I’m only really half way through making the first episode. The bulk of the levels are actually from the original Qbasic version, which are obviously quite limited. I’ve built a system for playing Adlib music, but haven’t made any music yet, appart from tracks for testing the software anyway.

CGA in game.

CGA in game.

So why am I releasing it? Well because despite the limitations it’s pretty cool, and I have fun playing it. (one of the reasons progress has been slow!) I want to motivate myself to get busy making more levels, now I realise there will probably be little interest in it, but stuff that I post about on my blog tends to get worked on. So having it here is a great motivation for doing more work and perhaps reporting progress as I get more done.

I’ve put a ZIP file on my download site here.



Adding CGA to Bob’s Fury

Bob's Fury Title Screen

Bob’s Fury Title Screen

As a small project I decided to add CGA graphics capability to my DOS platform game, Bob’s Fury. I have already implemented EGA, VGA (mode 13h) and VESA (640×400) modes. I had hoped to be able to run the game on older machines including 286 class machines as a minimum specification. The trouble being that the EGA mode tends to be a bit slower because of the way its video memory is laid out (planar mode). VGA mode 13h works quite well, but machines of that vintage do not necessarily have a VGA card.

Bob's Fury gameplay

Bob’s Fury Gameplay

Early 286 machines were about 6-8Mhz, but had speed advantage over 8086/8088 machines because of being a more advanced processor. Later 286 machines got to about 16-20Mhz on average, but as high as 25Mhz about the time the 386 came out. This makes the 286 class an interesting beast as performance can vary quite a bit not only based on the processor, but also the speed of the RAM and chipset. It also spanned quite a change in graphics capability as it started when CGA was standard and lived until the early days of VGA.

Hence my desire to add CGA support.

EGA Screenshot

EGA Screenshot

I haven’t written my own graphics drivers for the game, partly because that’s tones of work especially if you want to support multiple video cards. I’m using Borland’s Turbo Pascal 6.0 and I used the Graph unit built-in. It uses drivers stored in BGI files so you can write an application that works with a number of video cards and modes. This has made the programming relatively easy to add new graphics modes, which is part of the reason I started adding support for older cards. I have heard the disadvantage of the BGI/Graph system is that is can be slower performance wise compared with assembly code.

My main problem adding CGA support is the same as before, converting my existing VGA artwork to a 4 colour palette. I had solved this problem for 16 colours when I initially added EGA support with a horizontally doubled resolution, but because the only CGA modes with colour are 320×200 I wasn’t going to be able to do the exact same thing again.

CGA in game.

CGA in-game.

I eventually worked out technique that I’m happy with. It’s a little bit more complex than the technique for EGA because of the very limited number of colours. I allocate CGA colours to the most commonly used VGA ones, then using the neighbouring pixels work out what the best CGA colour would be for the remaining VGA colours.

Whoa thats a lot of green!

Whoa that’s a lot of green!

The end result is ok for CGA, but clearly not as good as the other modes. After testing I found it was quite a bit faster than EGA, but not as fast as VGA as expected. It means the game should run on a 286 of pretty much any type now. Whether they are slow or fast and have CGA,EGA, or VGA.


Thexder like EGA graphics conversion for Bobs Fury.

Recently I had decided to add EGA graphics to my DOS based platform game, Bobs Fury. The difficult part of course is converting the VGA 256 colour graphics to something in EGA that would look something like the original. I did not like the idea of manually converting or recreating the art work so I set upon creating a converter program that would do the work for the 150 different sprites in the game. The first kind of conversion I tried was basically mapping of colours in the sprites to the best match of a single colour in the standard EGA palette. I measured the difference in colour for each channel (red, green and blue) and added them together as a basic measurement of how different they were. This resulted in some odd colour choices by the converter. It picked brown in some cases where a green would have been more appropriate, and some other sprites where just way out of whack! At this point I also discovered that the graphics system would not allow me to use the 320x200x16 ega mode that I had planned on using. For Bobs Fury I’ve been using the Borland Graphics Interface (BGI) for drawing within the game as it allowed me to support a few different graphic modes without writing several low-level libraries for each graphics mode. It was also partly because when I started writing the game I didn’t have the experience necessary to create the low-level graphics libraries required. The best resolution that fit the game screen turned out to be 640x200x16 as the higher modes don’t have enough vertical resolution to deal with the higher resolution mode sprites I had created. It was at this point that I remembered the game Thexder and how it used the same mode to try to accomplish a very similar goal. You can see some details of this as recorded by Gemini (Kris Asick) on his web show Ancient Dos Games, click here for Thexder and here for Thexder the Second Contact. I decided I could probably modify my converter to double the horizontal resolution of the sprites, using two pixels instead of one for each in the low resolution sprites. Using a similar algorithm to before I did get some nice results, but still also some weird ones which didn’t even come close to the original at all. I was starting to think it wasn’t possible and that I’d have to convert the images manually when I was struck by an idea that actually comes from matrix math and 3D graphics. I decided to change how I measured the difference between two colours. What I did was to treat all the colours like vectors, and measure the angle between them and difference in length to decide which ones were closest in colour. Once I had picked the primary EGA colour that was the closest match, I went through a similar process to pick the second one. Adding it to the first and correcting the gamma so I could compare the final vector against the vector of the original. This seems to have given the best results that I could hope for, and has saved me a ton of work recreating the sprites in EGA. See the pictures bellow for a comparison of the VGA to the final EGA result.

Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way


MS-DOS game reviews, retro ramblings and more...