History of Space Invaders
(VMU style)


WARNING : I got bored writing this so do not expect it to a) make sense and b) be complete.

HOW I GOT HERE, WHERE I AM GOING

Back in 1999, I closely followed the development and launch of the Sega Dreamcast, waiting for Xmas to get my hands on one.

While waiting I found many websites dedicated to the new games machine and heard whispers of a site where you could create your own animations for the Dreamcast memory unit.
In my travels I came across the excellent www.levelsix.com which detailed the new process of creating animations on a PC with the dream animator and then uploading them to www.booyaka.com where they were converted into the files that could be downloaded with a Dreamcast onto the VMU.

Cool, but I still did not have a Dreamcast or VMU.
I trawled the Dreamcast websites looking for information about the web capabilities of the Dreamcast browser.

I was reliably informed that the Dreamcast browser would fully support Java and JavaScript.

I feverishly set about constructing a Java applet that could read and play these new animation files, sure that every animator would want this applet to preview their work on his/her site.

JVMU was born, it had taken many months and was able to load both the LCD files and the VMI/VMS files.

Finally at XMAS I had a Dreamcast and a VMU, but to my horror I found the Dreamcast browser had NO Java support only JavaScript.

Meanwhile conversations on www.booyaka.com message boards gave me a new lease of life as it came to light full programs/games could be written for the VMU.

Armed with the assembler and emulator (check out the VMU FAQ for details on where to get the versions most relevant to your system) I began work on Space Invaders.

The small amounts of source code available at the time had little or no comments so when I came across Tyro's skeleton.s file with full comments/explanations, my adventure into coding began.

I created the loading screen and other graphics in a normal image editing program and then using IMG2BYTE converted them to include files compatible with the assembler.

I started by creating a routine that could determine where in the LCD memory a specified line began.

then a routine to offset a byte (8 pixels) on the previously referenced line.

and finally a function that would loop through these to draw a sprite (see the ARROW DEMO )

next I made an array of the aliens and allowed them to be drawn in much the same way.

I made these move, animating as they went, when they hit the side of the screen they went down one line and back the other way.

Checking to see if they had hit the edge was a little more complicated than I though as any number of aliens could be dead.

The same was true for hitting the player at the bottom.

Most important was the players shots, I had originally envisaged the player firing many shots at a time but due to the size of the screen this was limited to just one.

The missile flies from the player straight up until it hits an alien, I had major problems here so when Morb made his debug enabled emulator available I was eternally grateful.

Finally I scrapped the entire shot hit system and rewrote it from scratch to just check if the missile's top pixel hits one of the aliens bottom pixels (rather than any pixel of the missile hits any pixel of an alien).

The loading screen made use of MARCUS's original setscr routine so no problem there, I did plan to have the [PRESS A] as a complete separate screen but instead decided to make it a masked label.
By taking the setscr function and hacking it about a bit I managed to get it to AND a bitmask to clear parts of the screen and then OR'd the image data on top, this allowed me to use the same function on the score and gameover screens.

By now the game actually played like a game (I added the score/level information screen) but when the action got a bit frantic everything got very flashy and hard to see.

It was the way the game accessed the LCD screen, each time the shot/alien or player moved it was first XOR'd from the screen and then redrawn in the new position, problem being, the user could see this 'clearing' of parts of the screen.

I need an offscreen buffer where I could draw and clear parts virtually before updating the LCD screen. I wrote the OSBLIT routine to copy data from the work RAM to the LCD memory and converted all the previous drawing functions by simply substituting

XBNK with VRMAD2
2 with VRMAD1
@R2 with VTRBF
(If none of that makes sense look in at the pages at Marcus's Dreamcast/Hardware/VMS and John's detailed memory/BIOS info pages )

And then, right at the end I added Night/Day mode via the internal VMU clock, if you start the game with the clock at an odd number of seconds you play at night, if its even then in the day time.

My next project will be a small one armed bandit simulator.

Neither I nor this site is in anyway affiliated with SEGA and the excellent work they do.
I am not responsible for anything that works or does not work including files and pages made available at www.jumpstation.co.uk
I am also not responsible for any information(or what you or others do with it) available at www.jumpstation.co.uk
 In fact I'm not responsible for anything ever, so there!

very long source