Xeo3: Multiplexor...

I've been sitting here playing with a C64 multiplexor - boy has it been a long time since I did this! Actually, reading about Dan's one from Armalyte is what got me doing the port in the fist place. Armalyte was probably the best looking game to come out on the C64, so I had a read through his source and got back in the mood. Pretty interesting it was too, I'd never really used the stack much since I tended to stick to zero page lda/sta as it was one cycle quicker, but his multiplexor sort approach was novel. So, I did some tests on it and compared it to the one I had in Blood Money... His varaied quite a lot and either gained a few scanlines or lost a few depending on sprite order etc. Mine is pretty much static (unless theres < MAXSPRITES on screen, in which case it gains) so I've decided to stick with mine for now, particually since it does a proper sort, while Dan's is an approximation (which is usually good enough for a multiplexor).

So now that its all sorted, I'm just about to start on the actual fun stuff! Building new raster interrupts based on where a sprite needs to go. When I first used this in Blood Money (after hacking Armalyte to find out how he did it), I thought it was very cool indeed. In fact, it took me a while to actually believe thats what he was doing - very cool stuff. In Ballistix, I'd gone with a static array as documented by Braybrook in Morpheus, and since I HAD to control 32 sprites for that, it was probably a fairly wise course of action. But for Blood Money, I could use something more flexible, and after seeing Armalyte, I just had to know how he did it.

Anyway, I'm about to do it again. I'm not quite sure if I'll follow his IRQ routine either, as I hate maintaining large unrolled loops. Im sure at some point in the future I can unroll it if I need to.

OH! And I've just discovered a 4th C64 that I have, and its the older ones with the original SID chip in it, so I can at last listen to all the old classics on the machine itself! Ahh...bliss.

Xeo3: Sprite time...

Luca's given me a new batch of sprites to bundle together so while I've been doing that, I've also been updating Luca's scripting build so that he gets all the latest features. While doing so I've fixed the parent+child system. This allows small sprites to be joined and act as a single BIG sprite. Luca's been playing with a large mid level baddie, but it wasn't working right. Turns out when I had rewriten the killsprite routine I had inadvertantly broken the link system. I'm not terribly happy with the fix however, as it means I have to loop though all the sprites every time one is killed. Its not the end of the world, but I dont really have any spare FLAG bits to enable me to fix it.
I've only 2 left, and I think I need these for other features. Luca wants to be able to orbit baddies around parents, and I'll need a flag for that, I also need a flag for something else...but that escapes me just now. I may well have to admit defeat and add another FLAG byte, but I really dont want to do that.

I got my Retro Replay today!! Very cool! I think I'll probably get the RRNet and SilverSurfer add on as well as it'll let me squirt stuff down rather than having to copy it to the MMC card all the time. Using a RetroReplay and the MMC64 I can now mount a D64 image and read it like a normal disk, which is very funky - its now a pitty that so many have "custom" loaders that dont work with it! At least Blood Money and Ballistix seem to, well... they manage to load, but blood money then crashes when you start playing, no idea why - seems to have all the graphics and code it needs.

Xeo3: Playing shuffleboard with the C64....

I've been shuffling around the C64 code and data for a couple of reasons really. 1st It means I can use the music as is without having it relocate it, and second buy changing the VIC bank to $4000-$7fff it gives me a few extra sprites. It got me going for a while though until I discovered a bug in my IRQ code which was always setting a bit in the screen address, this meant I could only have screens at $0400 and $0c00 and it took me a while to track down exactly why this was. Vice came to the rescue with a reasonable debugger, although I really wish they would add some basic symbol table support. Being able to put a breakpoint on a label address is a godsend! Anyway, bug fixed, code and data all moved around... and I now have 160 sprite slots, and a few more above the panel.

I also workout out that if I changed the format of the +4 sprite a little, I could squeze in 199 sprites, quite a bit up on the 167 we already have! It depends if I get around it it... its not a huge change as it just involves making a 300 byte xply table and changing the cache pointers from pointers to indexes (theres only 147). But that would save 8 bytes per sprite * 167 sprites... a lot! I hope I get a chance to make the change, although Luca might not thank me, he already has a lot of space to fill!

XeO3: C64 sprites....

I'm having a little coding break at the moment. I thought I'd have a quick play and see how much bigger the sprites feel when theres a proper C64 sized one in the level. It's not a lot bigger really, but I suspect a few of these larger ones and it'll start feeling a little cramped. I was pleased as punch when I discovered an old copy of Tony Crowthers 3in1 graphics editor that I used to use, it does sprites, characters, backgrounds and has a scratch page for playing with ideas.... great little C64 editor. I've not really seen it on the NET anywhere so I really should upload it somewhere for folk to use, coz it really is fab.

XeO3: C64....

Not a bad evenings work! I've managed to get the sprites converted over as well! Although at somepoint I guess I'd have to get them redrawn since they are only 16x16 but still, it looks great with the added colour! I'll probably release a C64 teaser in the near future as well, lets see if any C64 guys get interested :)

XeO3: Surprise Surprise!!!

Well, in only 2 days, I've done the main part of the port to the C64! Although there are no sprite graphics yet, and no multiplexor, its running through the game and its paths. Alien Bullets are off a bit for some reason, but that should be an easy one, unfortunately because the Plus/4 one has been designed to run in 2 frames, the C64 one runs a bit quick. I can slow it down to 2 frames as well, but I'm not sure I want to yet. Past experiance says that when you're PLAYING the game, you dont notice, and 2 frames gives you a lot of free time to do cool things. Because of Hardware Sprites, I can however move the players ship every frame, which will help make it seem like's going quicker than it is... I could also scroll the screen by 1 pixel a frame as well, but I dont think thats gonna work becasue sprites that are supposed to be attached to the background will judder - I think.

I've just been thinking, if I move the VIC bank to $4000-$7fff, then I'll be able to use more or less the same memory map, and use Luca's SID music as is (since it sits at $1800 - currently right in the middle of my sprites!) It would be nice to use his music, as it helps round out a demo.....

XeO3: C64

I'm having fun with the C64 just now while Luca gathers together some sprites for me to use, but I've hit my first snag.... The MCM on the plus4 uses differnt bits than the C64! Damn. So, I've done a bit flipper to swap bits $01 and $10. This lets the colour RAM on the C64 do the bright colour (since in MCM on the C64 you only have a choice of 8), and the 2 full colour registers then make up the rest... This will work fine for the game graphics, but......... The panel has some HiRes graphics in it...Damn, damn.....

So looks like I'll have to do a character index and tell it the ones I WANT to swap...bugger. However, once thats done it should just be a matter of importing Plus4 graphics and using them directly! Initally I'll do a port routine for the Plus4 sprites as well, then I'll get them resized. The C64 sprites are 24x21 (or 12x21 in MCM), while the Plus4 ones are 16x16 so there quite a bit of extra space there! The reason for the odd sizes is simpky that it lets the C64 have a sprite every 64 bytes, making 256 in a VIC bank.

I think I can get the whole thing up and running (without sprites) pretty quickly, then I'll need to get a multiplexor going... and then that "should" be it! :)

(in theory....) Imagine doing a "dual" retro release!! How cool is that!!! Now... if only I could persuade Russell (Kay - Lemmings PC programmer) to write the spectrum one...Mmmmm.... That WOULD be a complete rewrite though...

XeO3: bits and bobs...

Sound is interesting.... you can work away trying to get perfect pitch and volume and then when its working just the way you want, you can sometimes make it really course and never notice the difference. I put keys for volume control into the game, and all the work spent on the ADSR (a whole day of it...) is reduced somewhat to a whimper depending on the volume. Now, when playing back on the actual machine TED sounds are far FAR louder than Solder's SID chip addon, so I need to set a volume of around 2 or 3. This means all my ADSR values of 7 down to 0 are now just 2 or 3 down to 0. Not a lot... But they do still count, because if you dont use ADSR at all, it sounds terrible... weird.

I have to confess, I've been playing with some C64 code tonight.... I found the source to the Armalyte Multiplexor on (Lemon64), and thought I'd go through it... and perhaps get it up and running. However, this has lead me to look back at my Blood Money multiplexor (which itself was based on me hacking Armalyte - although I wrote it myself once I had the gernal idea), and its not bad either... theirs is a bit larger with the loops unrolled a lot, but mine wasn't too bad at all. Anyway, I think with very minimal work (and a working multiplexor) I can get XeO3 up and running pretty quickly on the C64. I'm kinda half waiting on Luca to do some more sprites now anyway, so I've an excuse to play a little... well... thats my reason and I'm sticking to it! It will be a little harder to get .PRG's onto the C64, although my MMC64 will help a bit, but a download cable would be much better.....

So, after looking through the source, I've started to macro it a bit more to make it easier to follow - for the sort at least, I may well write my own multiplexor bit again... but I suspect I'll try and get something running first. The great thing about doing a C64->Plus4 or a Plus4>C64 conversion is that being 6502, it'll just run - I won't have to rewite it all the way I used to do when doing a port. This means I get to do all the fun stuff and dont have to do ANY of the boring stuff again!!! Great!!!

XeO3: Sounds....V2

Weel, I've gotten 2 channels...almost - but good enough I think. Basically, I now have 2 full effects playing and both use ADSR envelopes, however channel 1 (Square wave only channel) will now check to see if its ADSR value is bigger than channel 2's sound. This means that either channel can get louder if sounds overlap, but you don't really notice that much, and having 2 channels is much nicer.

I'm also starting to feel the pinch, and memory is becoming tight. I've had to do my first code shuffle since code space was over running, so I've moved lots of local function variables into the games DATA area, which I've now expanded by 2k to make room for it. This isn't something thats gonna improve, it'll just get worse. It also leads me to wonder what the hell Im gonna do for a front end! Theres just NO space left for one, let alone character sets and all. I'm not a big fan of "loading" front ends since this is really bad news when you first start playing a game and get killed a lot, long load times don't make for a fun game.....

Speaking of long load times... I'm looking at the memory map and ralise that I'll need to load 3 seprate files per level; it would be much nicer if I could make it one big one, load times would drop quite a bit. I'll have to see if its possible to shuffle things around to be able to do that.

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.