I know some people don’t like using flickering methods to get more colours, but I was reminded of why I went down this route when I looked back at my oldest, 4 colour version of the game started in the late eighties. Black, Green, Grey and a changing background colour were to be used throughout the game; I think it would have ended up looking very dull indeed.
Richard Phipps of Reflected Games dropped me an e-mail a little while back, offering some great words of encouragement. Although he’s now programming some lovely shareware games for PC, he still remembers a lot of technical details about the Atari 8-bit. We exchanged some ideas about getting more colours on screen, and he even whipped up some simulated screenshots for me (see below). These ideas involved mixing GTIA modes (9 or 16 colour, but low resolution) with higher resolution (but limited colour) modes on alternate scan lines, and then interlacing the screen to make the scan lines merge. Unlike the best modes for displaying lots of colour on the Atari, some of these modes can be done without having to use Display List Interrupts on every scan line or tying the processor to a display kernel routine, which both leave few CPU cycles to do anything else. The lack of colour resolution on these modes can make for some strange artifacting around colour boundaries, and overlaps of moving objects can look a bit messy (reminiscent of the infamous Sinclair Spectrum colour clash), so chances are I’m not going to use these modes. There doesn’t seem to be anything new under the sun though – I recently saw CIN pictures for the first time, and it looks as though they work pretty much the same way!
By the way, be sure to check out Richard’s excellent original retro styled PC shoot’em up game, called Storm. It reminds me somewhat of Thrust or Oids in visual style, although most of the gameplay elements are different. A free demo or the full Shareware version can be downloaded from www.reflectedgames.com
Here are a few screenshots showing some of the latest reworked graphics from Stage 1 and 2
The past couple of months have seen me moving the game over to a cartridge format from the original disk format for Atari 130XE only. This is where most of the delay has come in, and it is still not back to where I left off with the disk version. However the good news is that some things are being improved due to the larger memory capacity of the cartridge as I go along:
Another visual change has been to make the score line more like the original. I didn’t think it would work out very well, but it seems to be okay. Thanks to Bryan Edewaard for suggesting it. By the way, Bryan has just produced an excellent version of the Atari Warlords arcade game for the Atari 8-bits called Castle Crisis
It’s been a while, so what’s been happening?
Most of the changes done since March are to do with getting the dragon riding bonus stage to work. The dragon’s called “Uriah”, and you control his left and right movement. The idea is to steer him into as much of the scenery as possible, and smash it up – makes a change from shooting everything I suppose. You get extra bonus score added at the end, depending on how many things you managed to hit. It’s a good place to really boost your score as each item hit gets 50,000 points bonus added. This screenshot is from the original:
Before starting Uriah, there were a few visual touches to add to the floor, and the top grid in Stage 4. The colours blend nicely from one colour to another on the floor and top grid, during the stage. Initially I hadn’t planned on adding this, as it’s purely cosmetic, and I thought it only happened on the three top grid stages; then I noticed there is actually a colour change in the floor during the Uriah stage too. So, what the heck, it wasn’t too difficult to add some colour changing code and make some room in my stage overlay file (this is the set of data that gets loaded at the start of every stage, and describes every aspect of it). Just a list of colours and a timer. The colour blending isn’t as good as the original, but this is something the Atari is quite good at compared to its peers. There’s a choice of 128 colours in the mode I’m using, and you only have to write colour registers instead of redrawing everything to make it a different colour.
Initially I wasn’t quite sure how I was going to do Uriah, but luckily things soon started to gel when I really got down to thinking about different approaches. Normally your player, the “Space Harrier” himself, is built from all 4 of the Atari’s hardware sprites (called player/missiles by Atari). They’re quick and easy to move around the screen, as opposed to having to draw and erase things yourself with a software routine. Naturally, because of this it’s wise to use them wherever possible – but they have quite a few limitations. You’ll notice in the screenshots, Space Harrier is sitting on Uriah’s head, and the other “segments” or tail pieces of Uriah get drawn over the top of him – simply because they’re behind him. Obvious to you or me, but not to the Atari. The hardware sprites can only be made to go over or behind certain colours – they know nothing about real 3D on their own. So did I try and work out where Uriah was going to be over Space Harrier, and then redraw the sprite armed with this information? Well…No. The way sprites are drawn is very different to how the rest of the screen is drawn, and mixing the two would mean creating some fairly slow code to do it. I decided to have Space Harrier represented by normal screen graphics for this stage. You’ll notice he has slightly different colours because of this. It also meant that the jumping on and off of Uriah could be dealt with by the existing pattern handler. Also there was the added bonus of being able to use the sprites for something else. Originally, I wasn’t going to have the overlaid tree counters that pop up on the screen as you hit more and more bits of scenery – but it turns out the hardware sprites are quite well suited to this task.
There were a few things that I hadn’t realized were going to be a problem with this approach of representing Space Harrier by normal screen graphics instead of sprites. For one, the animation routine I had built into the pattern handler for animating the aliens couldn’t make him run without a serious limp! So that had to be made better. I also had to go back on my self imposed limit of no more than 4 colours per object (to save disk space). I could have drawn Space Harrier and Uriah’s head as separate objects of 4 colours each, but it is much more efficient to treat them as one object – which would break my 4 colour file format. It seems a little wasteful, but Uriah has got his own file format now! However, if a cartridge version is done, there will be none of these 4 colour limitations. In fact, at the end of the day, I may just do a cartridge version, and not bother with the disk one at all. It won’t need a 130XE to run it either, any 64K XL/XE machine will do.
I thought getting Uriah’s undulating up and down motions, combining with the left and right control and the tail segments following on, was going to be one of the trickiest parts. But when I thought about it, I realized I had the right routines already in place. The normal alien patterns can do exactly this – they follow each other, and undulating them up and down is no problem. All I had to do was to add left/right control. This was very simple too. A function I added to my pattern handler (which I didn’t expect to use as much as I am), is the ability to run a predefined piece of code when required from within an alien attack pattern. So I just created a piece of code that overrides the x direction of the pattern, depending on where the joystick is. Hey presto! One Uriah coming up. A few more little pieces of code like this (which I call “pattern commands” if you’re looking through the source code), allow you to control Space Harrier while you’re waiting for Uriah, and to make sure you jump onto Uriah in the right place, amongst a few other things that have to be done just before you hop onto him.
Most recently I’ve been implementing the top grid which comes down on Stages 4,9 and 14. Here’s a screenshot of the original to give you some idea.
I thought I had already been through the code for doing the floor grid and the sky, but when I started going through it to incorporate the top grid, I found things could have been better. So I took some extra time out to try and improve them, while I was at it.
Another thing was adding the mirror function to the sprite loader. In Space Harrier you’ll notice there are often objects that are exactly the same, expect one is a mirror image of the other. E.G. The robot can face to the left with its gun pointing right, or it can face to the right with the gun pointing to the left. The arcade machine can mirror its sprites easily by telling the hardware just to draw it the other way round. Unfortunately the Atari is too slow to do this and has to waste memory by storing another sprite drawn facing the other way already. But during the loading of each stage there is enough time to do this, so we don’t need to store or load the extra sprite from the disk, just calculate it for use later.
I also did some fooling around with the sample playback routines. Although you don’t notice on a real Atari, on an emulator, you can hear some clicks and pops as the sample plays back. Part of this is due to the emulator having to resample to playback at a different rate from the original, but it highlights some timing difficulties in the game. Moving the position of when the horizontal colour changes (done with Display List Interrupts on the Atari), to either odd or even scan lines, makes a difference. I think it will sound a bit better now on emulators.
Recent Comments