| 20-Jun-05 |
Atari XL/XE Space Harrier Conversion Project
| Latest | Mar-07 | Aug-06 | May-05 | Feb-05 | Oct-04 | Aug-04 |
| Dec-03 | Mar-03 | Jan-03 | Dec-02 | Jun-02 | Apr-02 |
2nd Feb 2003
I've been pretty busy on Space Harrier the past few weeks. Below are some extra objects created for Stage 4. The process of creating them is a bit tedious, mainly because of the much greater graphical capabilities of the original arcade machine compared to the Atari:
The arcade machine uses a screen resolution of about 320x224. That may sound rather low compared to machines these days, but at only 160 pixels across the Atari is limited to half even that resolution. What's more the Atari allows only 4 colours at that resolution too, whereas the original has 256.
Of course there are some tricks to get around this limitation - in the case of this game I'm overlaying two of these 4 colour screens, and swapping rapidly between them. With the right colour choices this can produce the illusion of about 12 real colours, although the selection is somewhat limited. The real downside of this technique is the flickering that occurs on overlapping pixels of different brightness.
The sprites are all drawn and scaled by hardware on the arcade machine of course. All the Atari's hardware sprites put together could not even do one of the Space Harrier objects, and they cannot be scaled to any size (unless you count 2 or 4 times bigger as scaling). The software sprite routine I have produced barely has time to draw all of the objects, let alone scale them as well. It also runs at a frame rate that is only 1/3 the speed of the original - and it has been heavily optimized too. The simple solution to the lack of scaling is to have many different frames of the objects drawn at progressively smaller sizes.
So the whole tedious process goes something like this:
- I create a screen grab from MAME, when the object is at its largest size
- Then into Paint Shop Pro to extract the object from the surroundings
- Then scale it down to Atari resolutions and colours, and centre it up nicely.
- It usually looks a mess after this, so tidy it up and simplify the object
- Next the harder bit - make all the smaller frames by scaling down the object more...it was a mess at the largest size, even more of a mess at the smaller sizes!
- Save it, and run my custom tools (sadly written in MS Access and VBA) on the object and its frames to get it into a file suitable for the Atari and calculate the sizes for collision detection
OK, was that tedious enough for you? Right. Let's move onto something else then...
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 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 scanlines, makes a difference. I think it will sound a bit better now on emulators.
For those into this kind of thing, here's a copy of the current source code, which I've spent a bit of time cleaning up slightly for my own benefit. This is a bit of a risk for me, exposing my amateur coding style to everybody. I've left all my embarrassing comments in for your entertainment too. I can't pretend to be a great coder, so if anyone notices things that can be done better (preferably much better), I'd love you to let me know. I'm sure there are many things that can be, but hopefully there are some neat things in there too. I've spent over a thousand hours on this project so far, over the years. Remember this is work in progress, there's still things to implement, and I've only really fully optimized the things where the program spends most of its time - sprite drawing and screen clearing. Note that the routines used during loading are (supposed to be) optimized for lesser memory space rather than speed. I've not included any data (which is stored in separate files for clarity), so you won't be able to assemble it as is. For those of you who missed the start it's for the ATasm assembler, which is basically the same as MAC/65, but any text editor will read it.
SH.ASM (Update - sorry - not going to post any more unfinished code!)
I'll keep posting the updated code every so often. Until the next time then. Chris.
