Resurrected Entertainment

Archive for July, 2008

Neverball: Under the Hood – Part #1

July 29, 2008

I’m a big fan of the Monkey Ball series produced by Sega. Sadly, I can’t just bring the game everywhere I go since it’s shackled to a console, and you just don’t get the same experience on one of the portables. So to get my 3D rolling ball fix more easily on the road, I have turned to a game called Neverball. Neverball is actually two games in one package; the second game is called Neverputt. It’s a GPL licensed game, so you can fool around with it to your heart’s content and maybe even contribute something worthwhile back to the project when you’re done.

Which brings me to the focus for this series of articles, we are going to add some functionality to the Neverball game. But before we can inject a new feature, it helps to understand how the game works and the architecture of the software; otherwise, we risk adding code which is either buggy, incomplete, or just awful. Since I really appreciate the stream-lined codebase for this project, I definetly do not want to sully the project using inferior source code, but that doesn’t really concern me since every drop of code I write is pure gold.

As a logical first step, let’s review the overall structure of the project. If you download it from the project’s website, you will be given a choice of packaging suitable for Windows, Linux, or Mac OS X platforms. For the most part, I’ll be focusing on the Linux platform, since it tends to be my development platform of choice in the here and now (although that’s quickly changing to the Mac). However, I will not forget about the other two and will relay any useful information for those platforms when I come across it.

Neverball has a simple build file using to generate the executables and compiled map data, although there is a Microsoft Visual Studio specific project file so you are saved from toiling with Cygwin. You should have little difficulty in getting it to compile using your favourite Linux distribution. It has dependencies on a few SDL libraries like SDL_image, SDL_ttf, and SDL_mixer. I would also recommend developing and testing this program on a machine using 3D hardware acceleration. Depending on the sophistication of your CPU, software emulation may not be terribly fast and can prove frustrating when you’re jumping into the game so frequently.

The project is structured into basically four pieces: data, modules specific to Neverball, modules specific to Neverputt, and the shared source code used by both programs. Between the two projects, Neverball is the larger and more full featured game. Neverputt uses the same rendering engine but customizes the game setup, layout, camera, etc. to suit the game of golf. The 3D rendering is entirely performed through OpenGL; there are no DirectX dependencies which is a boon for us since it makes the project more consistent and easier to modify.

The underlying engine uses objects and maps constructed from within a program called Gtk Radiant. I believe the most compatible version for Neverball would be 1.5, but 1.4 or earlier may work as well. A word of caution, the Gtk Radiant project does not build particularly easily on Mac OS X 10.5. You can find pre-built versions on the Internet via a small variety of sites, or you can simply download it here. In the next article, we’ll look at how to set up Gtk Radiant and get it working; we’ll also be looking at some of the higher level architectural pieces which makes the world of Neverball come to life.

Qt for Games – Niblet #3

July 24, 2008

During the development of this project, there are going to be things which Qt simply can’t, won’t, or doesn’t do. I am going to talk about a few of the features which must be implemented using other libraries, or if you’re feeling particularly creative, by writing large chunks of hand-crafted code. Besides being 100% organic, it also gives you a lot of background knowledge and can grow into its own project.

The first missing piece of functionality falls into the realm of input controls. While Qt can easily handle mouse and keyboard input, it cannot handle joysticks. Joysticks have numerous buttons and features, some of which can be accessed through standard interfaces; others require special drivers and access methods. Support for most typical joysticks can be easily implemented using a library like SDL. This is exactly what we will be using for Niblet. It would be cumbersome to try and incorporate SDL directly into our code, so we will be writing a wrapper or integrating it into one of the core classes and emitting Qt signals when input is detected. Since this sort of input almost always requires a polling mechanism, it will need to be done in the main game loop at some point. Careful planning will be required so that our game play doesn’t suffer as a result of this new input method. Ultimately, if it doesn’t work out to the benefit of the game, then it will not be used.

Qt does have support for audio, but that support is extremely limited especially when you want to anything other than your basic audio functions like playing, pausing, or stopping a sound. As I said, it’s pretty basic, so we’ll be using the OpenAL audio system. It’s flexible, clean, cross-platform and open-sourced. It has more than enough functionality for Niblet, so it seems to be the better choice over similar audio libraries, such as SDL_mixer, whose future is not so certain. Even though on some platforms, the underlying implementation may in fact be OpenAL.

Other libraries for additional mathematics, physics, and OpenGL support, such as GLUT, will probably be used since (spoiler) at least some of Niblet will be rendered in 3D. At least, that’s the plan since I want to see how well the two technologies can work together. There are many physics engines to choose from such as Box2D, Bullet, and Open Dynamics Engine. Many of these libraries also support collision detection which is a fine candidate for third party support.

Last but not least is the build system. We are currently using Qt’s qmake utility which takes Qt project files and produces native project files for different development platforms. It’s a pretty basic tool by itself and doesn’t offer any platform discovery functionality. For example, using a build framework like autotools or cmake, one can write helper scripts which perform tests, discover libraries and header files, and execute tools which can be very useful for cross platform projects. The need is especially great when your project needs to be built easily by other people with a minimum of fuss. Niblet is not going to be a huge project by any stretch of the imagination, so qmake will do just fine. It’s used to generate the build files for the entire Qt framework after all. Should I be struck by a desire to move to something more sophisticated in the future, don’t be surprised.

Politicians Make the Best Scientists

July 23, 2008

 This could be the beginnings of political science?

Qt for Games – Niblet #2

July 22, 2008

I had my first attempt at a brainstorm for project Niblet last night. I used the software program called Curio to collect my ideas in a synergistic, multi-media, power-house document. Too bad you only get to see the rasterized and PDFized versions. A few people have scoffed at my desire to use Curio, they asked “why not just use a piece of paper and pencil?” Aside from the obvious cool software motivation, I often have the need urge to put stuff like this on-line in the off chance someone may find it useful or interesting better than most of the crap on MySpace. It’s a fool’s dream but there you have it.

Niblet brain dump in Curio

The project has been extended to include addtional modules (mostly empty) and some additional framework functionality which allows me to suspend or activate game play amoung other things. The game’s scene area has also been enlarged and auto-scrolls when Niblet approaches the borders of the viewport.

Instead of me wasting time assembling a .zip file every time I want to release an update, I’ll just refer you to this handy-dandy Subversion URL. You can check out the project using this command:

$ svn co

Qt for Games – Niblet #1

July 19, 2008

A few days ago, I decided to experiment with Qt as it applies to game development. You haven’t heard of Qt? Well, it’s an SDK for cross-platform development which has really started to take off in the cross-platform arena over the last couple of years. KDE, a desktop platform for Linux, is based on the Qt library; so is the VOIP application called Skype. They even have a mobile platform called Qtopia for those who are interested in small devices. You can find out more information on the Trolltech website.

To begin the project and to get the brain juices flowing (after the second cup of coffee, of course), I wanted to come up with a small, interactive demo which would make use of some of the classes related to QSceneGraph and QGraphicsItem. I also wanted to play around with the layers a little bit and see how suitable they would be for games. The first program is a simple one indeed; in fact, it’s not really a game at all – unless of course you’re really bored and you start to chase invisible dots on your screen. Just run demo, and you’ll understand what I’m talking about.

I am basing this project off a classic so that I don’t stray too far off topic. MS-DOS 5.0 shipped with a QBasic game called Nibbles. The game play revolves around a worm that you control through a maze of walls while looking for food. If your worm collides with a wall or itself, you lose one life. The difficulty revolves around the worm’s velocity; it gets faster as you advance. The idea is to use that basic game as a model at first and build on it a little as time goes on; this will help to keep the project focused, which can be a real challenge for those who are new to game programming. To get things started, I have decided to dub the codename for the project: Niblet. The real name will be decided, if and when, this Qt game comes together.

The first problem is the worm, of course. It needs to snake around and grow to certain lengths when food pellets are ingested (or numbers as was the case in the original game).; I also like the idea of it shrinking in response to an item collected during the progression through a level. Anyway, the rules can be fleshed out later. For now, let’s just get a very basic framework up and running. To compile the little demo, just run qmake and then make if you’re on Linux or open up the project in Xcode if you’re using Mac OS X; Windows users can open the project in Microsoft Visual Studio. If you’re using Mac OS X Leopard, I suggest you try out Qt 4.4 which will produce a proper project file for Xcode 3.1.

Dynamic Path Demo using Qt

As you can see, very little code is needed when using Qt. If you were to write the same program for Windows using DirectX or even through the GDI, you would need considerably more code just to handle the application start-up process and surface initialization. But that’s the beauty of these SDKs, they essentially handle a lot of the routine programming so you can concentrate on building your software faster and better using these handy libraries.


July 18, 2008

There are two ways to render graphics in DOS. The first involves setting the desired graphics mode and then drawing pixels on the screen via the BIOS or writing directly to video memory (an interesting topic by itself); the second method involves staying in text mode and drawing pictures with the standard set of ASCII or IBM’s Extended ASCII characters (thanks to Telecom Corner for the chart).


While scripting batch files, you can also make use of ANSI escape sequences to control the cursor, display coloured or blinking text, etc. In case your interested, DOS requires an ANSI driver in order to translate these escape sequences. These escape sequences are non-intuitive and look something like this:


Ahh. Isn’t it cute? Many people have been discreetly killed for creating less offensive syntax than that. In addition to the regular set of ASCII characters which can be used in creative and artistic ways to produce a recognizable picture, using the set of extended ASCII characters provides an easy way to draw connected lines within the grid of displayable characters. When creating your picture keep in mind the screen size, since this is dependent on the video mode (some video modes can display more rows and columns).

TheDRAW Title ScreenTheDRAW was written by Ian E. Davis and was last released in October of 1993. It is a program which allows you to paint a picture or create an animation using these special characters and ANSI attributes. It’s not like painting individual pixels, you are limited by the set of characters available. However, this hasn’t stopped ASCII artists from creating fantastic content. The most stunning examples I found were on Bulletin Board Systems. They were often themed according to design of the on-line system. Using TheDRAW, these pictures could be exported as ANSI-compliant or ASCII text files, or as header files to be used in other programming languages. There are a number of small tools available for translating these files into other formats used by other languages.

TheDRAW package is bundled with a utility called TheGrab which can take an screen shot of a running program. It’s not your typical screen shot utility which takes snap shots of any graphics screen. This program works only for text mode screens and will output a file in ANSI, ASCII, COM, or TheDRAW format files. Be wary of using this memory resident utility under DOSBox 0.72 as it will crash and force you to end your session.

Last but not least, TheDRAW package is bundled with a utility for creating your own fonts to be used in TheDRAW paint program. This is without a doubt one of my favourite features and makes creating screens a breeze. There are many fonts available in the wide, wide world so have fun.

All of these features are thuroughly explained in the documentation and in-program help. Many of my programs took on a more professional and fun look because of this drawing tool; although I think I went overboard in some cases. I still find it the best tool available for doing this sort of work in DOS, although I’m sure many of you may prefer other software such as AcidDRAW.

Development Hell, Part II

July 4, 2008

Ok, so after creating a proper boot disk on a Mac computer, which would have been a pain in the neck if I didn’t have Windows XP installed in VMWare Fusion, and moving the BIOS reflashing software and image onto the diskette, I slapped the diskette into the floppy drive and fired up the machine. Nothing happens as the system refused to boot using the diskette. The 3 1/2″ drive was the “B:” drive and, of course, this particular BIOS doesn’t recognize the “B:” drive as a candidate drive in the boot sequence. Normally, I would have just used the “Swap Drives” option in the BIOS, but if you’ve read the last post, you’ll know my BIOS seems to have a bad case of Alzheimer’s. With my back against the wall, I knew the only option was to tear my carefully installed ribbon cables apart, and after the customary floppy drive error due to misaligned cable, I was ready to begin the process again. Knowing I was nearing my goal, I hurriedly rebooted and began flashing the EPROM with all haste. After following a few poorly worded prompts and trying to digest the jumbled documentation, the process was complete at last. Content with the success of the operation, I rebooted the machine and waited for the uncorrupted BIOS to work its magic. Exhausted and more than a little frustrated at having to reconfigure the BIOS for the twentieth time, I was treated to a marvelous sight:

“CMOS Checksum error – Defaults loaded.”

The Spectacular Rise and Fall of Commodore

July 3, 2008

On the Edge (Cover)I finished the book entitled “On the Edge: The Spectacular Rise and Fall of Commodore” a few weeks ago and I wanted to share some insight into the book’s content.

Back in the late seventies and early eighties, there was a lot of heavy and dirty competition between the fledgling computer companies of that era. Because many of the hardware engineers and executives from different companies knew each other, often the competition rose to personal attacks not often seen today. This aggression is evident in the books written by these people or the journalists who are trying to capture the tension during the personal computer revolution. Brian Bagnall’s book reveals many interesting tidbits of information, although some were easier to extract than others as the stories often overlapped and flip-flopped. In certain chapters, the text feels very biased and the passages from former employees are often rife with bitterness and frustration seeping from their words. These emotions actually helped to propel me into the book, since it seemed like I had something invested in finishing it, just like they invested their time and even their life to building those wonderful machines. Some of the people involved (like Chuck Peddle) were obviously still licking their wounds even after three decades. They’ll claim indifference, but if the quotes are at all accurate, there’s a seething tension which becomes obvious as the book plays out. You will walk away from this book feeling a much deeper connection to your favourite Commodore machine, be it an Amiga 2000+, Commodore 64, or the Commodore PET to name just a few. I would recommend this book to anyone interested in the technological developments during this time period and the people who made it happen.

Development Hell, Part I

The Heart of the Beast I want to build some software I received the other day, and I’ve been trying to resurrect one of my older boxes as a development machine after it failed to boot. First it seemed to be a power supply issue as one of the hard drives was failing to spin up correctly. After changing to a different supply and more power, it still refused to work correctly. I began to suspect the hard drive, so I imaged the disk using Mac OS X via the dd command, which was horribly slow but did make a successful backup. Once the backup was transferred to the new drive, again a very slow process, I shoved it in and turned on the juice. Sadly, it still didn’t boot. By now, my wife is chiding me saying I should just toss it and use something more modern. I immediately reversed my polarity and deflected those negative comments back at the beast (of course, I mean this in the best possible way, like a cute little beasty-weasty for example). Refusing to give up I focused on the new error glowing steadily on the monitor.

“CMOS Checksum error – Defaults loaded”

Usually this is caused by a dying battery. Rolling up my sleeves, I went and bought a replacement, cleared the CMOS, saved a new configuration using Award’s snazzy 1997 BIOS interface and… presto! Nothing changed. I tried this a couple of times with no luck. Before I reset the CMOS, I noticed something odd. It seems the jumper was set in the clear position for a while. I’m not sure for how long exactly, but the last time I exumed the motherboard from the old chassis I seem to remember the jumper falling off. With my attention focused on something else, I guess I just slid the jumper back on without checking the configuration. I’m wondering if that eventually lead to a small corruption in the original copy of the BIOS. Will a simple reflashing solve the problem, or will it lead us down a different path? Stay tuned for another exciting episode!