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

Trap for gwbasic

On a personal note, I recently became a dad again for the second time! So I’m quite tired and may not be very good at writing something intelligent, and todays entry will be short. The game I’m talking about today is called trap, and was written by Bruce Brandt in 1993 from what little information I could find on the internet. It was written in gwbasic and is now freeware. The game has no story, and is pretty basic. You move around a grid of rotating doors and your task is to trap the monsters that are travelling around in as little time as possible. Monsters will randomly teleport if you run into them directly or if you push a door into them. It’s surprising fun in short bursts in the same way that minesweeper is. Once you figured out the best ways to trap the monsters you can get you time down quite quickly. I was able to finish the game in about a minute at best but usually take about 90-120 seconds. You’ll find that it gets more difficult based on where the monsters start. If you find a monster at the edge of the map, it’s often a lot easier to force the monster to teleport than to try to trap him where he is. Some times the starting position of the doors can be a hinderance, but you can usually get around this. Running the game is pretty easy if you’re used to running programs in gwbasic, but there is also a pre-compiled DOS version around as well. It’s quite a difficult game to locate on the internet these days, but if you search for the author’s name and the word trap you should be able to locate it within an old BBS archive still around on the internet. I originally got it from a shareware disc from a magazine that my older brother bought so searching along those lines may also help.

The instructions for the game.

High scores

Game play screen

Qbasic

Qbasic Intro Screen

Back when I was at high school we got some newish 486 workstations in our computer labs. Fortunately for me they had a copy of Qbasic on them which I quickly put to use. Qbasic is the language I primarily used whilst I was at high school, I wrote many larger projects than I ever could with gwbasic with the knowledge I had at the time. One of the main differences was the ability to use non-numeric labels that could mean something, and the ability to have functions separate to the main body of code. As I learned to use these features my code got neater and easier to modify, which was a good thing because the projects got significantly larger! I only ever had the version that came for free with ms-dos 6 so I couldn’t use many features that other Qbasic programmers use. This didn’t really matter cause at the time I had no other programmers (and no internet) to help guide me on how to use features and hardware directly that I had no prior knowledge of. This meant that I only really used whatever I could invent easily, or find in the user guide for Qbasic or the reference manual for gwbasic. Here are some of the projects that I made during these years.

Flight

Flight game screen

This was originally a game written in gwbasic based on some space ship/jet designs me and my brother built out of lego. Here I had added many new features that were a lot like those found in the game f117a by microprose. The main goal of the game is to destroy land facilities whilst avoiding planes and SAM radar installations. The graphics were generated by vectors mostly and the small icons for the tactical display were created using the draw statement. The draw statement generated graphics in pretty much the same way as you would use the turtle in the logo language. You gave the cursor instructions on where to go and which colours to use. This was good in that I could draw images of any size and not worry about the amount of memory used, but bad in that the amount of detail was quite limited. Really it was more suited to gwbasic where I initially used this technique. One of the features in this version I learned in maths class in school. Yes, trigonometry at school helped me make the players plane fly using proper vectors flying at all angles instead of the 8 directions many games offered. Who would have thought something at school would turn out to be useful!

Puzzle and Mazing

Puzzle game screen

One thing I did do quite a bit when learning something new was write a clone of another game to practise the technique. Most of the time the clones were a shadow of the original and puzzle is definitely one of those clones. Back in the day we used to play a game called Squarez deluxe by Adam Pederson rather a lot, I was just starting out with the bitmapped graphics and had completed two very simple games in gwbasic called jump and dodge. So to try out some ideas I had for having a lot of bitmaps I started to write a clone of squarez of sorts. I first started writing puzzle in gwbasic before I had Qbasic. I quickly ran into problems running out of memory partly because I didn’t know how to save memory on the graphics. When I got Qbasic I migrated the code across and built the rest of the game. You only got to place one tile at a time, and they usually did their thing as soon as you placed them. It was pretty much a matter of luck as to how the game played out, but this was one of the first games I built that had more than just a few sprites in them. The code became a horrible mess because I didn’t use the function feature of qbasic, and there were many remnants of the old gwbasic line numbers and code around.

Mazing game screen

Puzzle did spawn a somewhat more original game design in mazing. I took the basic tiles from puzzle and scattered them randomly around a play field, with the numbers of each tile weighted according to a difficulty level. The player had to navigate through the play field from the bottom to the top, activating some tiles as they go to help them reach the end. Some tiles blocked you from moving, some trapped you and others cleared portions of the field. You got points based on the tiles you triggered instead of a time frame reaching the exit. So when playing against another player you could lose in the sense that you didn’t make the exit, but win based on points. The code for this game was not really any better than puzzle, mostly because it was based of the puzzle code. But given that it was an experiment in game design it kinda worked alright as a game.

Bobs fury

Bobs Fury game screen

One of my favourite genres of game is the platform game. Back in the day I used to play two games in particular a lot, both Xargon and Hocus Pocus. They inspired me to want to make a proper original platform game of my own. Working with my younger brother we created a simple platform game. I did the programming as my younger brother was a bit young to be able to do it, and my younger brother helped me with some of the graphics and level design. The game engine was a lot more limited than I really wanted to make when I first started, we were stuck with only two screens per level, and I couldn’t program scrolling at the time. A lot of features were cut out, I had wanted water levels like some of those that were in Xargon, as well as the normal ones within a castle or other area. But with my limited skills (and the limitations of Qbasic) we couldn’t add levels like that.  The code was a lot neater as this was one of the first programs that I wrote that used the qbasic function support. Using functions made the code a lot easier to read, but I still had a lot of bad coding habits from gwbasic, and from being self-taught. The game itself is playable but quite slow, although this could be because I’m testing it in dosbox, I believe some delay loops could be the issue. We made something like 40 or 50 different levels so there was plenty of content. I made a very basic music system for the pc speaker (via the play statement) that had a short bit of music looping that can get a bit annoying after a while. The collision detection wasn’t always the best either, mostly having issues with collisions with wall tiles rather than monsters.

Tomb game screen

I later used this engine to create another platform game called tomb, that was kinda based on an idea I saw in a magazine, a game called Pharaohs Tomb that I was not going to be able to get (but now have).  The game was different because you couldn’t kill the monsters and they couldn’t hurt you by shooting. You had to avoid the enemies whilst trying to collect the treasure. We created a different boss, either shown as a sphinx or mummy it walked back and forth across the level.

I’ve since made a Pascal port of Bobs Fury adding many features that I hadn’t even thought of back then, but remaining true enough to the old game to be able to play the old levels. I still continue to work on that version to this day, and probably have some more features to add!

Weird

Weird game screen

Yes one of my old qbasic games is named weird. This one is another attempted clone of Squarez, but one that worked out a whole lot better in game play. In order to score you have to put tiles togethor so that there are 3 or more surrounding the last tile you place. The tiles still come out individually, so it’s still not on par with squarez, but it’s quite playable and the graphics are weird to fit in with the name. Code wise it is a heap neater than it’s puzzle ancestor, but it is still all in one lump without functions. I’m not sure when in the time scale I wrote this one.

War

War game screen

A game we played quite often was civilization, but one feature that was missing from the DOS version was some simple multiplayer support. Hot-seat play would have been fine by us as we only has the one machine! So I decided to create a simplified war game based on how you fight wars in civilization. War is played as a hot seat game, has some basic units you can build, a single screen map, and some simple to manage cities for each player. The goal being to destroy the enemies cities. I did make a basic AI, but it wasn’t very good. There are several versions of the game adapted to different scenarios and differing levels of advancement in the engine. This was one of the last games I wrote for Qbasic, and it pushes the limits in terms of complexity and sheer size in both code and memory usage. Fortunately it’s also one of the better designed games, mainly because it had to be. The user interface isn’t as well designed as I’d like, but I was running out of memory to add any thing extra. It plays quite well, and speed doesn’t seem to be an issue.

Conclusion

Qbasic Gorillas

Qbasic is a powerful language for learning to program. The feature set is better than older versions of basic by a long way, encouraging programmers to make neater code, not by forcing you to, but by providing a better means of writing the same thing. I personally got a lot out of writing the projects that I did, not all my code was well written, in fact I think a lot of it wasn’t, but I learned a lot in the process. There are not many good languages good for learner programmers that also give you the power to create more complex applications. Qbasic fits the bill in many ways, but is difficult to get working on modern machines. So if you have an interest in programming I suggest you use QB64 which is basically a clone of Qbasic for modern systems with many added features, but compatibility with the old Qbasic. Microsoft also have made a nice starter language in small basic, but it is not compatible with Qbasic, which wont be a problem if you don’t require it.

Fvwm on NetBSD

Back when I first started university the computer labs in the engineering faculty used to mostly be filled with a type of thin client called a X terminal connected to servers running Solaris. This was my first exposure to pretty much any kind of Unix at all. Fortunately having been using DOS for many years meant that I learned the basic Unix bash shell pretty quickly to do normal run of the mill stuff. The window manager installed on pretty much all the Solaris servers you could access was fvwm. It was set up in pretty the default way, but with almost no modules started up by default, if I remember correctly they had the clock, the pager, xbiff and a rxvt window. I believe they had it set up this way because of the large number of X terminals they had (I’d guess a couple of hundred when I first started uni) and because they wanted to reduce network and server load for when there was a large number of students on the servers. As an end-user it was adequate, but the features of fvwm were definitely under utilised. The X terminals were not popular amongst the other engineering students, probably partly because they weren’t trained in their use, and because they were set up mostly with software engineering students in mind. This is why amongst my friends and myself, we often prefered using the X terminals because we would be guaranteed that we would get a computer when most of the other labs were full to the brim! There were also another two labs that instead of X terminals, had proper Solaris workstations in them. One had some old lunchbox style sparc stations that were a bit slow if you connected to the localhost. The other one had relatively fast Pentium (I don’t know what they were) intel based workstations there.

FVWM now

Pretty much every Unix distribution I’ve used of late either has a package for FVWM and an option to install it, or is quite capable of running it after being compiled from source. The base configuration has a lot more turned on by default than the university had, but it is still pretty sparse. Configuration of the program is done via a config file in your home directory, which can be quite daunting if you’re not used to setting up programs this way. The configuration file however allows for a crazy amount of customisation and given time you can make your desktop emulate most of the different popular operating system interfaces. The default has the window decorations looking very much like the window manager from motif/cde, but you can change the window decorations as you see fit, again using the configuration file. Some distributions have it already customised, for instance Debian adds its normal Debian menu into fvwm and updates it dynamically with software you install. Back when I was using Red hat Linux there was a perl based (I think) configuration wizard that helped you install themes.

The Good

One of the best parts about it is the fact that it is so light on resources. I’m running it on my old sparc station, it only has about 384 meg of ram and two 50Mhz processors, and fvwm runs as fast as if it were on a modern machine. The memory footprint is very small. It is incredibly customisable as I mentioned before, many people have created themes and configurations that you can borrow from. There are many scripts out there that implement most features you could want out of a window manager. The base configuration isn’t very pretty, but certainly functional.

The Bad

Changing the configuration can be difficult and may require scripting (or installation of scripts) to achieve the effect that you are after, which is obviously difficult for new users to do. Some distributions in the process of trying to make the most of fvwm, make their configuration files unreadable, and frankly un-friendly. This is a minor problem if you know how to make changes you want, but could be a major problem if you’re not prepared.

Conclusion

I tend to use fvwm in its default configuration with a few minor tweaks, partly because that’s what I’m used to, partly because that’s what I like. It’s what I use for any of my Linux/BSD systems that are a bit old or limited in resources, and even comes in handy when connecting to a powerful machine over the network via X. For power users who like to tinker with their window manager, you’ll enjoy using fvwm, and get a lot of satisfaction out of the result once you’ve completed your custom configuration. If you’re an ordinary user you might find the default settings adequate, but find it lacking when you want to change a simple setting.

FVWM on my Sparc