Workprint – July 2018

Things have been a little rough of late with everything being topped off with our thirteen-year-old dog King passing away on the 7th of June – he arrived here at the start of 2005 as a small, six week old bundle of fluff. I haven’t really been in a fit state for much of anything since then – I pretty much kept up with Retro Gamer and tried “powering through” and sticking to my blog schedules but only managed about half of the “planned” posts – and I was even quieter than usual on social media which is something of an achievement I suppose? I’ve just realised whilst writing this that it happened almost a month ago, but I’m still getting the occasional wobble when it would have been his dinner time…

I haven’t done much code since then, but the bulk of what I’ve written during that period has been “busy work” to keep my mind occupied more than anything else. Vallation hasn’t seen any attention because I didn’t dare sit down with anything that complicated where I could easily lose concentration halfway through modifying something important and leave myself with a steaming mess to knock the bugs out of later… I’m perfectly capable of doing things like that often enough as it is without any external encouragement!

One of the distractions was writing a game for the Spectrum for release under the C64CD brand. It’s pretty much done apart from needing quite a bit more level data, but now it’s that close to complete I’m sort of committed to finishing it as an entry for the venerable CSS Crap Game Competition. It’s crap in the sense that it’s incredibly simple as a game and my Z80 is shockingly bad to the point where I’m considering a disclaimer when the source goes up to Github warning people that it’s not there as a “learning tool” unless being used as an example of how things really shouldn’t be done. That doesn’t stop me being almost perversely proud of it for some reason?

Workprint – July 2017

Yes I’m running late with the workprint post again (or perhaps I should say “as usual”) but, now that I’ve settled back into playing with game code, there’s been some time over the last couple of weeks spent dabbling with Z80 and quite a bit of head scratching about how to do software sprites; I’ve got a sort of working routine on the Spectrum which lacks proper X movement right now, but a lot more thought is required because it can only deal with three or at a push four objects per frame that are ten by ten pixels. That’s crappy and I know the problem is down to my Z80 “skills” being tragically weak, although another project that shall remain nameless for the moment has recently taught me a few things that might help.

On the 6502 front, I’ve been doing a few tweaks to Hammer Down that have been pending for ages so that’s slowly creeping forwards. There’s also the option of doing a small, reasonably well documented C64 game perhaps under the Backward Engineering label (since it hasn’t seen action for a while) to release via C64CD but I haven’t decided what exactly. My “default setting” is a scrolling shooter of course and part of me is tempted to write something with a simplified attack wave engine similar to the one in Ash & Dave’s Pirates In Hyperspace where the enemies have speed values for X and Y which all get changed when a timer expires. C64CD releases are meant to be simple so should I boil the design down to the bare minimum like that or do something a little more involved I wonder? Again, further mental gymnastics are needed…

How our CD5 part works

So… erm yes, I said over at the Plus/4 World forums that I’d write a “how it works” for the Cosine contribution to Crackers’ Demo 5 and here it is girls and boys, only six months late! Generally speaking there are two actual effects in play, the forty by five byte luminance scroller running through the middle of the bitmapped logo and a sixteen by ten pixel DYCP which works in the regular 39 by 6 character workspace but splits it into two blocks which are four characters high at the top and bottom of the screen.

The DYCP isn’t doing anything majorly different to the other single character routines I’d released around the same time – the loops are all unrolled and there’s specially formatted character data for speed which was originally drawn with ProMotion (I’m actually using an older version) before being converted using my cheap and cheerless bitmap to raw data converter – except that it has two distinct versions of the clear and draw code; one starts from the left hand half of the first character and proceeds to draw across to the right whilst the other begins from the right hand half; the code then flips back and forth whenever the hardware scroll finishes a cycle. During what I’ll refer to as the “design phase” for want of a better term, I settled on wanting the four character high areas so the redraw has to happen during the logo and there was only enough time to render ten pixel high characters.

And since I mentioned the logo, it was originally drawn using C64-specific tool Project One (again, I’m using an older version… one of these days I’ll update all my tools) with the colours used representing luminances; that data was then converted for the Plus/4 with a small assembly language routine on the C64 (all it actually did was translate the C64 colour data and dump it into memory so I could save the results out with a virtual Action Replay cartridge) and all of the colour data was manually created as an included source file. Here’s the logo’s “before” picture when it was still on the C64:

Finally there’s the large luminance scroller; the TED keeps luminance and colour data separately for bitmap-based displays like the logo so one eight by eight pixel attribute cell has two bytes of information, one containing two nybbles of colour (values from $0 to $f for sixteen possible colours) and the other holding two nybbles of luminance data (this time values from $0 to $7 for eight possible brightnesses). The “trick” here is that the luminance has been limited to a maximum of $5 for every cell in the picture where the scroller can pass over it, so when that is added to the scroller’s buffer which is either $0 or $2 for each nybble there’s a noticeable hike in brightness. To keep things simple there’s a second copy of that luminance data used for reference.

And, apart from mentioning that the music was created by aNdy using Knaecketraecker, pretty much covers everything I think. The source code is available online for those brave enough to go prodding around it and I’ll have a go at answering questions if any arise.