In this post we’re going to take a look at sprites. A sprite is an object that moves across the background and is used for everything from baddies to players, bullets to explosions and sometimes for background animations.
In Ballisitix (my first game), I had been reading a Programming Diary by Andrew Braybrook, a series of articles in ZZap64 that he wrote while developing Morpheus. I was hooked on these as a kid, as they were technical, and a highly enjoyable insight into real game development – the dream, as it was back then. You can have a read of them here – I highly recommend it for any retro fans.
http://www.zzap64.co.uk/mentalprocre.html
Now Andrews way of doing a multiplexor was to have several fixed raster interrupts going down the screen – basically 5 or 6 sprite “zones”, and as a sprite moved from one to the other, that raster IRQ would take over displaying it. This is how I decided which zone a sprite would be in for Ballistix.
It’s pretty simple, and as the comments tell you, it allows for a sprite to be in BOTH zones – where the overlap. The zone was about 32 pixels in size, meaning I had 6 zones over the screen. I also only multiplexed 5 sprites, since the puck, and 2 player arrows could be anywhere and overlap all the time. getting 32 sprites out of 5 sprites wasn’t bad going…..
You can see above the different bands, and how each IRQ could setup the sprites in that band, moving them from earlier use, into this band.
Now this worked pretty well for totally random sprite movement, but is limiting for more “fixed” path movement. For scripted paths, you can take advantage of positioning, moving things apart if they start to glitch.
Now in steps Armalyte. For me, this is by far the best, and slickest shooter to grace the C64 – and by some margin. When I first saw this, I was staggered at the size of the baddies, and how smooth and glitch free it was, so much so… I used my Expert Cartridge to hack Armalyte to figure out exactly how they did it, and what I found, astounded me.
What Dan Phillips did, was to use dynamic raster interrupts, not the fixed bands that I’d previously used. This means you can use 8 sprites at the top, and when you need 8 more, a new raster interrupt is generated just above the next set of sprites, where it will set them up on demand. And it’s not just one new raster, it will generate as many as is needed. It was also smart, and would only setup a sprite if it needed to, leaving other sprites for future IRQs when need be.
This was an amazing piece of coding (and I’ve since found out that the wonderful Paul “Paulie” Hughes was the first to do it, and Dan “borrowed” it from him!😂), and it meant that baddies like the one above, worked seamlessly, because as the baddie moved UP, so did the IRQs, meaning a glitch free experience.
I was staggered. So staggered in fact, I pinched it.
Not directly of course, but I created my own system based on this what I’d figured out. What I came up with, generate IRQs in a similar way – though it did steal a lot of CPU time… but did the job.
Here you can see the system circa 1989, where each of those bars is a raster interrupt that’s been setup dynamically to setup the next set of sprites, allowing for a total of 16 baddies to fly around.
So in Blood Money, I multiplexed 6 sprites, as it was a simultaneous 2 player shooter and both players could be sitting next to each other.
A few years ago, I went back and managed to get my old code compiling again, and took a look at the multiplexor and the sorting – that BIG block of white at the bottom. It wasn’t super efficient, but then I’ve learnt a lot in the past 30+ years. I did however tinker with it, making it quite a bit nicer – and quicker, changing the sort, and making smarter choices in the IRQ setup.
Here you can see the newer version, far less setup and less IRQs being triggered, and the sort below – the white part of it, is much much faster, using the same method as Dan did interestingly, but utilising the stack to do the sorting smartly – very clever.
So to recap again, the idea is the same as Armalyte, sort all the sprites by “Y” coordinate, setup the initial 6 sprites in the Vertical Blank interrupt (just after you sort them), then trigger a Raster IRQ a few raster lines above where you need the next sprite. If there are a few sprites close together, then set them all up, if they are spread apart a bit, then setup the next IRQ to handle them.
The reason you can’t just set them all up again, is because you might have the 6th sprite just below you, but the 12th is miles down the screen. So if you were to set them all up when you needed the 7th, you’d glitch the 6th. The trick however, is to batch as many as you can into each IRQ, to save wasting time, and that’s what I improved in the image above.
At some point, I’d love to go back and change that crappy starfield…. it’s ALWAYS annoyed me, it should have been a classic “Delta” style parallax starfield, it would have added a lot.
Anyway… that’s how the multiplexor is done in Blood Money, thanks in no small part to the work of Dan Phillips (and Paul Hughes😂), and the Expert Cartridge!
I do have a lovely C64 framework (above) that I need to get up onto Github, that has 3 different options for a multiplexor, and keyboard and joystick control all built there. It was a zip on my blog, but github is the way to go now, so I’ll try and get that up there.
The image above has 30 sprites being multiplexed from 7 hardware sprites, and leaving enough time for a game in there…. You could of course drop that number to 24 or 16 to free up even more time, but it’s pretty optimal.
This is the little sample I’ve included, a little bomb jack example where you jump about on a bitmap screen and pickup “sprite” bombs.
it also has an SD card loader – though I’m not sure if they are all compatible these days… that would be nice if it was still valid, otherwise the “get sector” would need updating.