Parallax Home Games MSX Misc. Contact Us

Core Dump

Core Dump Work in progress The Gallery Technical information


Core Dump - Work In Progress

Episode 22

May 20, 1997: Moonsound and bits of code

Congratulations Yen-Ha!

Enemy sketches I've got a moonsound! Erm... well it's not really mine, I just borrowed it for a while (thanks Rob!) to experiment with it. To see if Core Dump will feature Moonsound music...

Well after some initial experimenting with the sounds and stuff, I'm now looking for the technical details. (And I just found it: Maarten ter Huurne (again!) has the technical info.) Whether new games will feature Moonsound music depends mainly on two factors:

  • How much extra effort will it take to make all this extra music?
  • (Not a problem for Turbo-R's) How quick can a replayer be? This depends on how the beastie really works, which I don't know yet.
Anyway, first tests looked promising. I cooked up some amazing music this weekend, and it was real good fun. Hmms.

first Black Cyclon item screen I also recovered some older graphics. The first thing was a very old sketch for a Black Cyclon menu screen. It never got in of course, because computers were used for selecting weapons, and the few items that remained didn't need such a big menu. I might re-use some of these items, 'coz they look kinda cool. Or so I think.

I looked through all my computer magazines again last week, and I have a lot of those! Most of the time this is quite inspiring, and it shows you which faults not to make! And Pat is at Dynamo (a Dutch music-festival) so I can't show off with the Moonsound. He won't like it. I will.

Akin humans And humans. Yes, the humans that walked around in Akin. They weren't brilliantly drawn, yet they did the job: look like humans. For Core Dump I'll need much more kinds of humans for all the characters, which will be quite a problem because Pat and I aren't really good at drawing humans.

I also designed a really cool new weapons system, but the idea is so good I can't reveal it yet (I never saw anything like it in computer games!). Enemies will use the weapon too, and it'll be...
I'm sorry. All this cryptic talking can't be too good for my readers.

On the technical front, I made some refinements to the parallell engine that coordinates everything. This included adding some functionality to the macro's that make enemy code look like it's sequential code, where in fact it is not. It looks something like this:

  bit 2,(ix+0)
  jr z,DoSomethingWithIt
  ld a,(ix+3)
  add a,5
The [wait] command is in fact a macro, which acts as a HALT(framerate)-like command in this context. It waits, say, four interrupts. It possibly destroys all registers, and you can NOT do this:
  push HL
  pop HL
, because the stack is not saved in this operation. These are the only things the coder needs to know. Now, he can just code the enemy as if it were a sequential bit of code. Yes yes. When you run the game however, all enemy code bits are run in parallel!

And what I improved was this: now the wait macro has an optional "ADR" argument. Say I want to move this object to the left until it runs off the map. At that point it is deleted.

   ld a,(ix+1)
   dec (ix+1)
   or a
   jp z,delete
   WAIT stupid_object
Now, after the wait, the program continues at the loop position. You just could have done this with:
   jp stupid_object
but because of the way the engine works the latter solution is much slower. (11 T-states lost every time!)

Also, I added a "deletion-vector" to the objects. Now, if an object is deleted for any reason at all (exploded, object table is full, new zone entered) it might just execute some last bit of code. This helps me to determine when a camera has lost track of its object. Ho hum. The director-code for the camera's is still giving me headaches. It turned out to be a really difficult problem. But I'm not one to give up easily.

Go on...

Parallax Home Games MSX Misc. Contact Us