Posts Tagged ‘code’

Workprint – November 2017

Friday, November 3rd, 2017

I’ve decided to try a few little changes around here; for a start I want to stick to a schedule (goodness, I used the S word and it almost looked like I meant it too!) so from now onwards all workprint posts will appear on the first Friday of a month like this one is doing. That probably doesn’t sound like a major shift to most people but, as certain editors will no doubt attest, I’m a teensy bit rubbish with deadlines and even worse without! At some point over the “festive season” there’s going to be a few other changes too, but those are still in what I’m rather euphamistically referring to as “the planning stages”.

As far as programming goes, the scrolling shoot ’em up Rubidius in progress for the Hex Files rewrite is coming along slowly but surely with the most recent feature added is the subroutine that preps the engine for the start of a level; previously it was hardwired to just one map and block of attack wave data but now it deals with multiple levels correctly… although that wasn’t the case for several hours! When the new routines went in last Sunday they worked fine with the first level but would start doing bizarre things that should have been impossible during the second, including glitching entire tile rows. Remember kids, always keep a track of your “set in stone” subroutines because sometimes…

In this case the background scroller spreads the load out over eight frames and a couple of missed RTS commands (which I suspect were left out when the colour scrolling was added to previously empty “slots”) meant that, along with the update that was meant to happen on a specific frame, one of the other routines would be called out of sequence as well. I have no idea why the problem only manifested on the second level map though…

Workprint – October 2017

Thursday, October 12th, 2017

Things have been a bit… meh recently. I caught a cold at the end of last month and am notoriously bad at recovering from illness so didn’t sit down to do as much programming as I’d wanted to; I have done some code on a scrolling shoot ’em up which is for the Hex Files rewrite although it isn’t anywhere near finished just yet. It’s called Rubidius because even work-in-progress projects need a name and is running with some unused graphics which currently look like this…

…but there’s a distinct possibility that things will change as the project progresses. It’s deliberately a simple game internally – the attack wave driver is more primitive than the code in Edge Grinder for example – but I’m avoiding things like unrolled loops or self modifying code. Keeping things simple has, rather ironically, been a little complicated since I wanted to scroll the colour RAM but still keep things PAL and NTSC compatible.

Andy Vaisey has graciously agreed to compose the music for both Rubidius and the other game I have in mind which is a reworking of the original Hex Files sprite dodging one, although I haven’t randomly plucked a name from the periodic table and flipped a letter or two out for the title of that one yet.

Workprint – September 2017

Tuesday, September 5th, 2017

The lack of releases means this blog has been even quieter than usual… but things continue to happen in the background. For example, the rewrite of the Hex Files is still in the “exploratory stage” as I settle on an assembler and IDE to target, rethink the running order and actually start doing a bit of writing. CBM prg Studio initially looked promising but I really didn’t like the way it converts tabs to spaces in the source code; I’m used to whizzing around with the cursor keys so it feels somewhat stodgy. A few other options have popped up (feel free to insert a Finbarr Saunders reference here both for “popped up” and “insert”) so I’ll have to see if they feel any more comfortable.

Last month’s post also received a slightly less than subtle comment about Vallation. I forgot to mention it in said post, but it was the first piece of game code I started prodding around and a few changes have been made. The problem is that they’re not exciting enough to write about, essentially boiling down to just reorganising the memory layout to shift all of the graphics from bank 1 to bank 3 which makes space for extra level data required to expand the game out. At the moment this is all pretty much irrelevant until the end of game code is properly repurposed to act as an end of world event (each world is planned to be three levels sharing a graphical theme and, hopefully, some bespoke enemies) because it still stops after the original three levels unless I remove the checks, in which case the player instead gets deliberately stuck on the first screen of level 5’s map because it’s not done yet!