Bob’s Fury Update: Bug Hunting

I’ve been doing some coding on Bob’s fury lately, basically making adjustments and making code faster in the hope that I could make it work well on a 286 class machine. I have been using dosbox to develop and test, but this doesn’t fully test the compatibility or stability of software as dosbox has its own quirks and does not behave exactly as real hardware does. This is where my old Microbyte 386sx computer steps in, here’s a photo from when I first bought it.

It has been very useful for performance testings as it has a turbo feature that is software controlled. You can not only toggle the CPU speed with a key stroke, but you can set the slower speed in the BIOS configuration. This has allowed me to test with the machine running at its stock 20Mhz as well as a slower speed, I’ve used 10Mhz for my testing as a rough equivalent of many 286 machines. The testing I was able to do has shown that my game should be playable on a 286 depending on the video mode. CGA and VGA both have acceptable speed for game play, whilst EGA is marginal.

The testing did however uncover a rather annoying and difficult to squish bug. If I have the sound turned on (PC speaker is all this machine supports) the system will freeze when a game event that plays the explosion sound happens. Hunting bugs such as this are difficult as there is little feedback about the potential causes. It sounds like the code supporting the PC speaker should be at fault, so that’s where I began the search for the bug.

For the PC speaker I found a support library many years ago that allowed you to use the music macro language used by the play statement in GWbasic and QBasic. It hooks interrupt 1Ch (the system timer interrupt) to update the state of the PC speaker. Whilst I haven’t had any previous issues I wondered if there was a fault that could cause the crash. At first I wondered if using floating point instructions could have been the cause. The library has a small section using floating point to determine the number of ticks a note should last. On a system such as the 386sx without a FPU such instructions cause an interrupt so that emulation in software can take over. This interrupt within an interrupt was what I thought may be the cause.

So I constructed a test program hooking the same interrupt and performing a series of floating point calculations as a test, this didn’t yield the result I’d hoped as the test program worked fine. So I then wondered if the 386 was getting another type of problem that would cause an unwanted interrupt. So I copied sections of code from the library into the test program to run in a normal procedure that would show run-time error messages and debug information I could use. No run-time errors appeared and the results of the required calculations appeared to be correct.

I have a few ideas left to test, but I’m left with quite a puzzle regarding the cause. This does illustrate the need for testing on actual hardware, it’s usually better to test on many machines. Unfortunately I don’t have a large supply of 286 and 386 class machines, although I have a few I may be able to repair. I need to test on another machine because there could be something specific in the design of the Microbyte machine that isn’t compatible and is causing the issue.

Bob’s Fury progress update

You may have noticed that I’ve been playing with a number of homebrew MS-DOS games lately. This has given me a little more motivation to work on my own project, my simple flick-screen platform game Bob’s fury.

The main body of work left is to create the levels for the game and any content required for them. For me this has been the hardest and most time consuming aspect of making the game as it requires a lot of play testing and planning. Recently whilst visiting my folks I had some time to produce a new level, I’ve updated the download to include it.

I’m hoping that it won’t take as long to build the next level, I got one pretty decent tip from watching some interviews of Brenda Romero. Basically the tip is starting at the end/goal and build outwards from there. I had been doing the opposite, which made the process harder, partly because you have to keep where you’re going in mind before having built the area.

The other stumbling block I have is coming up with ideas for levels. There’s not much I can do to stream line this, so it will probably continue to be a road block. I will probably simply make fewer levels for each “episode” so I don’t require as many ideas.

I’ve also released the level editor for any one interested. You can find it here.

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

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

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.

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.

VGA Screenshot

EGA Screenshot