movem.l d0-d7/a0-a6,-(sp)

(Written 10/04/2007)

Googled for the Defender sourcecode and eventually found it. I’ve got the Amiga Format version of Blitz Basic 2 running in WinUAE in Parallels, but I’ll need to get the latest AmiBlitz working soon. Looking through the Defender code, I’m not sure how much use it’s going to be. Here’s a quick example:

x3=((xp+864) LSR 4)&127+95:y3=Int((y+28) LSR 3)

If x3<>hsx OR y3<>hsy Gosub alloff

    Use BitMap 2
    BlitMode EraseMode
    Blit 30,hsx,hsy
    BlitMode CookieMode
    Blit 30,x3,y3


    Use BitMap db
    Gosub allon

Aside from the fact that I can’t remember most of the Blitz-specific commands, we’re dealing with proper retro code here - no comments, meaninglessly short variable names, gosubs instead of functions and magic numbers. All of this junk is interspersed with this kind of thing:

MOVE #$0020,$dff09a

Yep, it’s Motorola 68000 assembly. Good job I bought those books on asm and the 68k CPU, really. Looks like they’ve used floating point (well, emulated floating point) maths, too. I’d rather avoid using floats if possible because they’re so slow, so I’ll probably have to rework the algorithms (if I can work the damn things out).

Started extracting the sound. Apparently sounds need to be in 8-bit signed RAW format. They’re currently in IFF-8SVX format, which is nothing more than 8-bit signed RAW with a header. If I can get hold of the 8SVX spec I can automate stripping the header and I won’t need to worry about converting the samples. Handy!

Windows problems are currently getting in the way of any further progress, though. My virtual Windows disk is now so fragmented that it’s taking forever to do anything at all. All stop whilst Windows defrags. Fortunately I didn’t bother to dual boot and kept Windows safely confined in Parallels, or I’d be stuck waiting for the damn thing to finish churning now. Deleted a load of stuff, too - won’t be needing the XNA framework or C# for a start.


Tidied up the destructor for the slideshow - it now runs multiple times without crashing. I wasn’t clearing the vector and one of the array properly. (Though running it too many times still crashes it - there’s something I’ve missed…)

Also made improvements to the menu system. Added a pointer back to the menu set for each menu, so I can store menu-wide variables in there. The menu set now contains pointers to the the button clicked/released sound files, for example. Menus also contain a pointer to their parent (if they are submenus) to enable the back button to work (when I write it). Enabled the clicked sound.

There were two tricky things here. The most difficult was getting the cyclic dependencies sorted out. As the menus contain a pointer to the menu set, and the menu set contains a vector of menus, we have a problem where file A includes file B, which includes file A. Cyclic dependency. The solution is to scrap the problematic include and replace it with a forward definition. So, instead of having this in “menuset.h”:

#include "menu.h"

using namespace std;

class MenuSet {
    vector menus;

We have this:


using namespace std;

class Menu;

class MenuSet {
    vector menus;

In the menuset.cpp file, we need to include both “menuset.h” and “menu.h”. This only works if we’re dealing with pointers. If we had a vector of menu objects, rather than pointers to menu objects, we’d be stuffed.

The second tricky problem was getting the sounds into the class. This is tricky because you need to pass in a pointer to the size of the sound, not just a pointer to the sound itself. The datatypes are:

const void *sound;
const u32 *sound_size;

The functions (defines, actually) that play back sounds expect the sound_size variable to have the name “sound_size”, where “sound” is the name of the sound. Just to make things more complicated, the docs for the PALib suggest that any sounds (with the name “name.raw” in the data directory) included in the project (with “#include “name.h”, where “name” is the name of the file minus the extension) will be available within the project as “name_raw” (where name is the name of the file minus the extension). In fact, they are available as just “name” (minus extension, etc).

I’ve also tidied up the menu system’s destructors. Random thoughts:

  • I wonder if I can write an OctaMED player? I vaguely remember the C sourcecode for the player and a description of the file format shipping with SoundStudio;
  • I wonder if I can make the high score save file adhere to the IFF standard? Just been reading about that, y’see…