XeO3: Sounds.....

I've been having a play would some sound effects just now, and for basic TED sounds.... its not bad really. I can only use one of the TED channels since I need to change the volume to create an ADSR envelope. Its a pitty since 2 channels would me a big difference to the overlapping nature of effects. Still, I've added in apriority system so firing sounds are drowned out by explosions, which in turn are drowmed out by pickups and so on. It means that at least theres some basic sound effects as well as music - normally you only get one or the other.

I've had to create a 64 byte volume table to allow the sound effect volume to be turned up/down. Since I use the volume to create the ADSR, I need a redirection table depending on what the volume actually is. For example, if we're at volume 4 then ADSR value of 4 becomes 2 (instead of staying 4 when SFX volume is 7). This means I can turn down effects smoothly just like the music.

XeO3: Pickups.

I've now added those commands; didn't take long, and now I've moved on to do the pickups. What I now have running is a set of 5 baddies where all of them need to be shot and the last one then explodes and drops a coin (or any pickup at all in fact). I had to add a NOSHOOT flag as well and make it different from NOCOLLISION so that you can't shoot the pickup, but explosions also won't harm you. I guess I could have left NOSHOOT out and just set the number of hits to something insane, but this feels a little cleaner. So now all I need to do is get instructions from Luca on how the weapons and pickups actually work! Then we can finish with this bit and move on. Also means Luca can plan out the levels a bit better with all the bits in the right places. I only have a couple of bits left - I hope I don't need to add too many more flags!

And...............rest.

After having been hard at work *ahem* doing the demo, I'm, having a nice relaxing day today. I've been sitting here scanning the old Zzap64 site and reading Braybrook's Morpheus diary again. I remember when it first came out, I was rivited! Actually reading day-to-day delveopment was great - this was before I was doing it myself of course. Great fun re-reading it, although some of it now seems a bit silly, but it was obviously designed to be read by non-professionals, and was well written for that. I've also been playing with my MMC64 (a card that plug into a C64 that lets it read+write MMC cards.), and its been great seeing some of the old demos+games again. I can also use it as a SID player while I work! Cool!

Seeing the power of the C64 again really makes me want to port the game over to it, theres SOOOO much more that could be done if I had Hardware sprites. More characters, more animations - more space in general!! Oh well... one thing at a time.... I might play with a multiplexor sometime soon though....just for fun.

Oh well, back to work I guess. Time to implement the new sprite group system, and add a couple of new commands for Luca (who's now learning how to use the scripting system). He needs SETFLAG <flag> and CLEARFLAG <flag> to allow some effects for certain alien types and shouldn't take long to add in. I've also decided I don't need STOPGROUP since you have to set a flag for it to be IN a group anyway, so if you dont want to be in a group, just don't set the flag!

XeO3: Power ups..

So, back to work then... I've been thinking on how to get powerups from baddies, and I reckon that the best way would be if you had to kill groups of them; miss any, and you dont get anything. So, what I need is a couple of script commands to help with this. So, I'll create RESETGROUP <index>, SETGROUP <index> and STOPGROUP. This will let me tie baddies together, but they'll also need a new GROUP flag so that I know I have to link them with the others.

To do this, I'll simply create a 8byte array (so I have 8 groups to play with at any one time) and after I issue a RESETGROUP in the path any sprite started with GROUP will simply increment the variable in the group array that we're currently using. Then, when it dies, decrement it. If something does die, and the counter goes to 0, then we can start the death path which then releases the power-up.

Should worl fairly well, and with SETGROUP , should let me have multiple groups on the go at once. Most I think will drop money, but some will drop weapons.... I think... Up to Luca I suspect :)

XeO3 scripts...

The cool thing about doing a script engine is that whenever you need a new feature or have a special case, you can simply add a new command for it. Which is exactly what I've done to help the Teaser demo; so now when it reaches the end of the level, instead of waiting for the BOSS (which isn't there - we dont want to give the whole game away!) the level will restart and you can watch it all again!

I've been throwing in a load of scripts to help fill up the level and its looking pretty good, but I don't expect many of these paths to be kept once we do the level properly We'll take a lot more care in placement than I've done with these quickies!

What really gets me with XeO3 on the Plus/4, is that its doing SOOO much work! If I ported it to the C64, I wouldn't have to draw any software sprites (although I might mask the baddie's bullets), and since running a multiplexor is actually fairly cheap, the game would fly!! I could also scroll the bloody screen properly rather than 2 pixels at once making it much smoother as well. Once the Plus/4 one's finished, who knows...I might port it over to the C64 - the basic game would "just run", and all I'd need to do is polish it. We'd also have a TON of characters freed up for even nicer backgrounds! I wonder if I could do a bitmap scroller so I could use colour...Mmmm... that'd be very cool.

XeO3 teaser....

Okay, so I've spoken to Luca, and we've both decided a teaser would be better as we don't want to give too much away, but we do both want to show the progress we're making. I think part of the reason for the demo is that people have to "see" it to believe that its not just all fiction, and to see that that we're not exaggerating on the website as to how good its looking.
So I've spent this evening putting in a TEASER assembley option so I can enable this whenever I want to. After 6 years, it'll be nice to get peoples reaction once they actually see it run!

Doing this also showed that the Plus4 would actually be capable of a simultaneous 2 player game! This would be amazing! 2 players on screen at once blasting away! But I'll leave that as a lesson for the reader.. :)

This demo has also showed up a bug in the sprite system, it wasn't setting the first frame of the sprite correctly, so thats now fixed.

Xeo3 - Turrets.

Bah!! Stupid mistake. I fixed the bug where by the first turret couldn't be shot. Turns out I was doing a BNE loop rather than BPL - DOH!! Oh well, that looks like the turrets are all fixed and working now. I might need to add a new bullet vector, but I'll wait and see how it all plays. So, now its back onto writing the supporting docs for Luca....

I've also been thinking about the demo Luca want's to release.... perhaps it shouldn't be playable, but just scroll by to show it all in motion - we don't want to spoil things too much! Once we have more path's completed - and weapons added in - I guess we can discuss it further.

Blog...

I've decided to reformat my Blog into a slightly wider format. The old layout was all very pretty, but the narrow window didn't allow for pictures and text very well. This layouts also much better for code to be displayed - hope you like it and it doesn't get you blue.

KillClip...

Mmmm.. Not quite done yet. Its about 10 lines of code, yet its not working... damn. For some reason the top bit in the Y coordinate is being set of some sprites, and this is leading them to get killed off as that takes it over $c0 which is past my kill line. It looks like it's suddenly jumping from $62 to $ca the first time the circle command is run - it also looks like its only happening because of the order the sprites are being allocated in - very odd.

Ahhh.... the wonders of debugging. Turns out that the PathLastCommand variable wasn't being reset when I reallocated the sprite to a new path, and the first time this sprite was being reused it had been killed while doing a circle command. This means it was never being initialised properly and so wasn't setup right. The circle command is pretty cool, but has a couple of issues. The first is that when you initially run the command it has to work out where the center of the new circle is - this allows you to start anywhere on the arc and smoothly run around it. The problem is it requires twice the work! First you need to do an inverse circle, then you need to do the command properly. Still it's a small price to pay for such a great script command.

I'm also busy doing a script tutorial for both Luca and anyone else that wants to do Shoot-Em-Up's with this game framework once its released. With any luck, it should mean that we get a steady supply of great shooters comming out from folk - and pretty quickly too. They should have the choice of simply re-skining it with different backgrounds and sprites and possibly different music+effects. Aside from things like animating turrets, it will mean that you get a completly different game without any coding at all. Of course, if you dont want turrets, you just don't put them in! The goal here I guess is to make it as data driven as possible.... but when that fails, then coders can go in and just change whatever they like!

I'm now having a look at the turret bug - they don't always restart once your dead. This turns out to be a simple one with the FreeTurretIndex not being reinitialised on a restart. However this has now taken a funny turn.... The first turret on screen is active and shooting, but I can't kill it..... how odd.

XeO3 scripting...

So, I started to document the scripting engine for Luca (The artist/musician/designer/programmer chap that's helping me) and I was trying out some of the sample I was putting in the document for him, only to discover that my KillClip flag isn't actually implemented yet - doh. KillClip is a great little tool. it allows you to write a script and set it off into an infinite loop, the script engine will first wait until its come on screen, and then when it goes off - it'll kill it. This helps make scripts easy, and removes some timing problems you sometimes get.

So, first I have to write this, then document it again. It's one of these simple but irritating little things as it does chew up a few instructions, so its just a matter of keeping it small. The usualy way is to do a bounding box check to the screen, but thats too much, so I've opted to try and be clever about it. I simply check for >320 and >186. This is because the sprite is still visible when its >0, and once its <0 we've wrapped around to 511... which IS >320. This means I only have 2 compares, and then its just a matter of keeping track of the bits and flags.

XeO3 - Begins again...

So, I thought I'd post some stuff I'm doing in my spare time. I'm currently writing a retro game called XeO3 (surprise surprise) which can be found at XeO3.org. This little game started life some 6 years or so ago in an effort to make a comunity sprite routine of all things. The problem with the Plus/4 is that unlike its big brother the C64, it has no hardware sprites, and unlike the Spectrum, software sprites are a nightmare to write due to its character map screen. So, I decided to try and apply some modern methods to this old problem and then release it out to the comunity so that there was a chance that some new games might get done - something beyond the simple ones that were currently being written.

I was getting on fairly well and had a few sprites running around so I started to think of a simple game to show it all off. I had suggested doing a breakout clone since it wouldn't take me very long but the community wanted more... much more. So, I then suggested a shoot-em-up since the plus/4 didnt have any good ones due to the lack of real sprites. In fact, whenever there were some real sprites, there was usually only a couple of baddies, and a very small play area. And so it began, and the long process of doing an old style game got underway.

Now, due to work and family (and boredom) limitations, it doesn't get worked on very often, and so has taken a long, long....LONG time. But its now getting to the point where real progress is being made, and its looking pretty good. The technology behind it is also pushing out what people thought the plus/4 was capable of as well which is good.

So, from here on.... I'll start to describe what Im doing to it.... The graphics/music/gameplay are documented via the main XeO3 blog, but I'll document the programming stuff here. Hope its of interest.