Overview Core Dump - Work In Progress Episode 22 May 20, 1997: Moonsound and bits of code Congratulations Yen-Ha! 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. 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. 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 WAIT 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 WAIT 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. stupid_object: 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: WAIT 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... Read the previous entry