Enemies!

Thursday, 8th September 2005

They claim a picture says a thousand words.
In this case, with these two pictures and one video [549 frames] I estimate that I have saved myself from having to write over half a million words in this journal entry.

There is, of course, the usual shonkily shot video footage to watch: 416KB AVI.
The collision rectangles need a little bit of fine-tuning and something better than just vanishing sprites needs to be implemented, but the modular and simple system is there.
Each level contains a pointer to an "attacks" table.
Each "attacks" table entry contains a $FF terminated list of attack patterns, in order.
Each attack pattern specifies -

• Which sprite number to use.
• A pointer to the routine to call to initialise the enemy sprite locations.
• A pointer to the routine to call to move each enemy sprite each frame.
• An attack time.

Each enemy is held in a table containing an X,Y coordinate and a "ticks" counter that is incremented each frame automatically.
The "attack time" timer is primed and decremented each frame, and once it hits zero the system moves to the next attack pattern from the level's list.
This means that I can have a number of different patterns. So far, I've implemented a simple sine-wave attack and an even simpler random-positions-and-drift-past attack (both from the original game), but some attacks are more complex, relating to paths or drifting towards the player. This system I have in place should make having a wide variety of different types of attack simple.
I got so far, compiled, ran on my Game Gear and - oh dear. Lots of nasty name table corruption. To save space, I had decided to check the bullets against the enemy ships inside the sprite-writing routine, which was obviously too slow (much popping, pushing and use of the index registers) and as such the sprites were being written after the screen had started to be displayed. I have moved the code outside the loop and restructured parts of the code, but I hope that I have enough time/space to implement other things properly, without being restricted too badly by the low CPU speed.

I'm not getting far with this elsewhere, so I'll ask here - anybody here with BBC Micro skills?
I really need help with the music side of things - not so much writing a sound/music engine for the game, but more the actual "porting". The BBC Micro has the EXACT SAME PSG in it, so I could probably write a modification for a BBC emulator (BeebEm, for example, comes with source) which logged writes to the PSG hardware port (and time-since-start-of-program), but I'd still have the piou-piou-piou-skrrch sound effects over the top. Does anyone have a BBC Micro disk with a copy of the Fire Track music on it? I remember seeing/using music collection disks which featured game music on them a decade ago, and SOMEONE must have a "raw" copy of the Fire Track music (how else is there a recording in the STH archives?) but nobody on the STH fora seem to be able to or want to help.