Tag Archives: code

Workprint – March 2019

Posted on by
5

One of my “defining traits” is a quite frankly ridiculous lack of organisational skills, in fact it comes as something of a surprise to people who’ve known me for any length of time that I get blog posts up on what are, by my standards, a fairly regular basis. As a result of that there are a lot of projects hanging around my hard disks which have been put aside for one reason or another, sometimes either on the cusp of being completed or actually done and dusted (although in one case it’s a port and in need of an overhaul since the original version has subsequently been improved).

So with spring approaching I plan to apply the defibrillator a few and right now I have two in mind, both of which C64CD projects; I’m keeping one close to my chest until it starts to properly exist past a few sprite routines that need recoding anyway, but the other is a reworking of Stercore 64 which re-imagines it as a bespoke C64 game rather than a Spectrum port. That’s more difficult than it might sound because the game scrolls at a character per frame and the landscape has two layers with one passing over the sprites, so my “plan” is to rely on the way that one of the character multicolours always remains behind the sprites regardless of the priority register.

That’ll give me a black background with one other colour for the background layer and, if I can scroll the colour RAM, five or six foreground colours; the sprites can then pass between the two without needing any complicated sprite clipping code since the hardware will do the work for me. That said, actually drawing something half decent with those restrictions is difficult and, whilst games like Implosion and Shadow Skimmer carry it off well, I’m no John Cassells or Mat Sneap…

Workprint – February 2019

Posted on by
2

So that’s January out of the way and, after the rush of throwing things out the door over the “festive” period, I seem to have come to something of a halt. I’m not sure what I actually want to work on right now and part of me is pondering the switch to game code… although Rassilon alone knows which project at this point. I have a few which are ridiculously close to finished and there’s a couple in the pending pile which need more attention but even choosing from those – including a few that have never been spoken of, apart from in hushed tones with other members of Cosine – will doubtless prove difficult.

There are a few less sensible ideas on the “to do” list that might get some attention as well though, most of them are partially complete projects filed under the “I wonder if” category and are more proof of concept than anything else. On top of that there’s a range of platforms I want to play with at some point, but those are going to require further research so probably aren’t going to go anywhere in the short term. Perhaps I need to take a couple of days to sit down and think about it…

Workprint – August 2018

Posted on by
Reply

As noted a few times recently, I’ve cycled over into “demo mode” and have been working on… well, something that I’ll be keeping quiet about for a little while yet until it properly gets past that stage where it could be changed or indeed completely reinvented on a whim. Generally speaking though, my intention is to have something ready for X’2018 in early November – assuming we have a representative to take it along – and have a cluster of prototype routines along with some other ideas I’ve been meaning to try and a folder of logos because everybody loves logos… right?

Things have been going slowly but surely so far – today alone I somehow managed to metaphorically paint myself into a corner on two different occasions with what should’ve been relatively simple code, either choosing a less than sensible place to store things or simply running out of memory altogether – and, because it’s been a painfully long time since I worked on anything that wasn’t a onefiler, last week saw me sitting down and trying to get my head around cruncher and loader integration with some of the more recent iterations of popular tools with very little joy… at least until I discovered lft’s Spindle that is.

Spindle is, in essence, a back engine for demos which deals with loading and decompressing of data to the point where the user doesn’t need to be involved; no fighting assemblers to build loader or decruncher code, no messing around with building disk images of data, just document the files being used and the order they’re needed via a script file which is then run through Spindle to automagically get a working disk image out the far end. There are caveats of course – a couple of places in memory have to be avoided, something else I bumped into today – but having to do things just a teensy bit differently is worth it for the results.

Main project aside, there’s also been a little time spent generally doodling both with graphics and ideas for effects and a couple of forays onto other platforms; something might come of the latter if they survive testing on real hardware – in both cases the code was for a platform I don’t actually own right now, so that’s something of an issue – but at the very least it was all good practice.