Just a quick sign of activity to say that the monitor-written shooter is pretty much functional now and only lacking background and wave data; that’ll take a few weeks because i’ve got other commitments to worry about right now, but it is at least getting there! The final title of the game is Edge Grinder by the way, because it has a bonus scoring mechanic based on scraping the edge of the player ship against the landscape! Here’s a pwitty if short video to stare at:

Just before I crawl off to bed, a couple of small observations about programming C64 games in a monitor that struck me earlier today – when building data tables, the urge to make everything fit in eight or sixteen byte runs is always there and working with a monitor generally promotes an “if it isn’t broke, don’t fix it” attitude. Sweeping statements yes, so I’ll have a go at explaining further with an example.

Up until about an hour ago, the eight bytes used to specify an enemy object gave it’s X and Y start, X speed, Y speed, animation sequence to use, colour, how many hits needed to kill it and the time to the next enemy; a new object was positioned just off screen, told how it looked and then kept following the line it was given until moving out of bounds and being decommissioned. Functional, but highly limited and it’d make coming up with interesting movement patterns that didn’t have to pass through the background at some point quite difficult.

So along comes the first dilemma; the code is already functioning and changing it will take quite a bit of reworking, so simply leaving things in a working form (because changing them risks thoroughly breaking the rest of the existing code) is extremely tempting. And the second dilemma was the data; when it’s being read from memory with the M command, the output is in blocks of eight bytes so nice and human readable, but the new command structure initially appeared to need nine so wouldn’t be as easy to examine and amend.

The solution I settled on, after some soul searching and deciding that staying with the existing system was just indolence, involves some hoop jumping; the code was modified to give a two state system (instead of just moving, enemies cycle between two sets of direction controls) and the data reorganised and optimised to keep everything within eight bytes. That optimisation requires some concessions, enemy movement speeds are now hardwired to two or four pixels on each axis when they were previously going any speed I fancied using and the colour and animation sequence data are occupying a nybble each of the same byte so a value of $0C means animation sequence zero with a colour of 12 (medium grey) and $45 is sequence 4 in dark green. Rather convoluted yes, but it’ll turn out easier to work with in the long run.