A Little C64 Update…

Wow, it’s been a while since I last did a blog post! A lot has happened since then…

For starters, my Briley Witch RPG has been a bit on/off as I work on other projects. One distraction was the RGCD 16k competition, and for that I coded a little SHMUP named Neutron. Neutron began as a Star Force inspired SHMUP back in the 80s when I had my original C64. The game was finished but sadly never released when the company Orpheus was closed down. All the original materials were lost ages ago, so this new version is a re-creation, using all the skills I’ve acquired over the years.

One of the first things to get sorted for Neutron was a generic sprite multiplexer. I did a bit of research and built one that can happily throw around up to 24 sprites on screen at once, more than enough for my needs. I’ve engineered the multiplexer to be as fast as possible, so all the interrupt routines consist of nothing but self-modified code made from lots of LDA #xx, STA $D0xx instructions; using self-modifying code also means the sprite IRQ code doesn’t need to stack/unstack the X and Y registers, making it a tad faster. I managed to code the system without the need for double-buffering, which keeps things simple. Sprite sorting is done during the game update loop, with the main raster IRQ performing the sprite setup, modifying all the code needed for the next frame’s sprite IRQs.

BTW, you can check out/download Neutron by following the link.

Also, the response to Neutron has been amazing, so I’m grateful for all the comments I’ve received. Makes me want to create more games!

But as a result of creating Neutron, I needed music making for it. Being the crazy girl I am, I coded my own music editor, one based on a player/editor named NinjaTracker. NinjaTracker caught my eye due to its relatively low CPU usage, and compact data. Perfect for a 16k cartridge competition. Since discovering NT, I’ve modified the player to work with my games, and built a PC based editor from scratch. The editor I’ve named SJTracker, and it works very well for my needs! Thinking of releasing it to the world some day, perhaps once I’ve sorted out the few issues I have with it…

I’m not really a musician, but I can make some tunes, and once I had a music editor, I created some tunes for my Briley Witch RPG, starting with simple tunes, progressing to more complex ones as I gained experience. I still have lots to learn, but I’m pleased with the results so far, and I can only get better…

So I decided to compose all the music for Neutron myself. Kinda glad I did as it meant I could create the music to be as compact as possible, even stripping out unused code from the music player just to claw back some space. For example, I managed to create the tunes without using any filters, so the filter code was removed (along with some NTSC detection/playback code).

With Neutron completed and entered into the competition, I went back to coding Briley, composing more music and adding that to the game, giving the game another play-through and adding in all the music triggers. Adding music to a game makes a big difference!

But I was worried about how much space all the music would take up for Briley… No worries, as current estimate is all the music taking up around 12-16k of cartridge space, which is pretty awesome when my initial estimate was around 64k!

But after the response to Neutron, I have to confess I have a bit of a SHMUP bug right now… Hence I’ve been busy coding another SHMUP, this time a side-scrolling game I’m calling SlipStar. At first, I was thinking of entering SlipStar into the 16k competition, but decided to drop that idea (I was making far too many compromises for my liking) and instead decided to create a full game.

SlipStar has given me the chance to experiment with some parallax scrolling, as well as coding a dual layer scrolling system. SlipStar is based on the engine I developed for Neutron, the biggest change being to convert the vertical scroll to horizontal. That didn’t take too long as they are both fundamentally the same: the screen is double-buffered, the CRAM scrolled by a block of generated code that’s just a mass of LDA $aaaa, STA $bbbb instructions for maximum speed. Double-buffering the screen means a background screen can be generated over several frames while the game is using the hardware smooth scroll. It’s good enough that I can get the sprite multiplexer setup and scroll completed before the end of the V-Blank period.

The sprite multiplexer I’ve reused from Neutron, the only problem being the number of player bullets on-screen. You see, the C64 can only display 8 hardware sprites on a line, so any game firing lots of player bullets horizontally will have a major problem with flickering sprites. But the multiplexer can support deliberate sprite flickering, (such as engine thrust and fast moving objects), with some sprites flickering on alternate frames to maximise the number of visible sprites per line.

After looking at other C64 SHMUPs, I coded up some player bullets that instead of using sprites, plot characters to the screen. It works, as they move fast enough for it to look okay. For larger, more powerful player weapons I still might use some sprites, so I’ll take a look at that later once I get the bulk of the game done. As with Neutron, I don’t want to make the player weapons too powerful; I can’t afford to go throwing too many sprites around, just enough to make the game fun and challenging to play.

This new game needs a lot of graphics, so I’ve been busy creating them, with the backgrounds for 15 background being created as I write this. Next comes the enemy sprites, as well as the bosses. Oh, and music…

I’ll also be adding a simple story line to the game, one that ties all the stages together and gives meaning to everything. The story will be told during the loading for each stage.

So currently, my plans are as follows:

1. Continue to work on and finish SlipStar.
2. Resume work on my Briley Witch RPG and finish that.
3. Return to Neutron and create a full version (using some tricks I’ve learned from SlipStar). The full version of Neutron will be titled “Neutron 2020”, and hopefully released next year.
4. Make more C64 games… I have loads of ideas, and I’m having fun, so why not?