Posts Tagged ‘December’

Workprint – December 2017

Friday, December 1st, 2017

Keeping with my “schedule”, it’s the first Friday of the month and time for a quick update… and yes, I’m as surprised as everybody else that this turned up on time!

Rubidius is slowly taking shape, it completed its first proper loop – going titles page to game and back with or without passing through the completion screen with the presentation stuff mostly being placeholder code – yesterday and I’ve got the score counter in and a test version of the music Andy is working on playing in the background. There’s nothing new to show right now because it doesn’t look much different to the previous screenshot, but some proper level graphics have been started and, once I get a certain writing deadline out of the way, I hope to find a few days to draw and install some actual backgrounds.

There has also been some pondering over the idea of writing a C64 game for C64CD in part as a demonstration of how easy it actually is; since scrolling shoot ’em ups are my default state it’ll almost certainly be one of those, but trying to keep things as simple as possible to the point it’ll essentially be a more primitive but tile-based version of Warflame. I have a few interesting ideas about “features” and the thought of publishing it in some form is amusing (to parody a certain person’s suggestion of Kickstarting a book based on his blog) but most of those options still need feasibility tests and bespoke code. This might also end up as the final resting place for the tiles that’ll soon be pulled from Rubidius as well.

How Koalatro works

Tuesday, May 16th, 2017

There were some interesting responses to Koalatro over at the CSDb when it was released, with a few people expressing surprise that the code only takes 16K which has left me giggling like a schoolgirl because, apart from some zero page use which doesn’t count towards the total according to the competition rules, the entire thing runs from 15K, loading and executing between $0400 and $3fff. A Koala-format bitmap is 10,001 bytes (8,000 of bitmap, 2,000 of colour and a byte for the background colour register), aNdy’s music takes around 3K and another half a K is taken up by unrolled code to open the borders and split sprite colours. So that’s about 13.5K use and the rest of the code, some tables, sprite definitions and a little scroll text therefore have to fit in the remaining 1.5K… right?

Well not exactly and it’s probably best to look at the memory map in order to explain further; before the code starts, the layout looks like this:

$0400 - $07e7	First block of colour RAM for the bitmap
$07e8 - $09db	Second block of colour RAM for the bitmap (packed)
$09dc		Background colour register
$0a00 - $13ff	Code, data and scroll text
$1400 - $1fff	Music
$2000 - $3f3f	Bitmap data
$3f40 - $3fff	Colour tables and sprite positioning/set-up data

The first two “tricks” are how colour for the bitmap has been stored; the first block at $0400 is already where it needs to be (which is why only the crunched file from the Github repository can be dragged and dropped into an emulator) so there’s no memory lost elsewhere or code required to move it into place. The second block of colour is a bit more involved since it’s been packed down into 50% of the RAM; this relies on the fact that only the lower nybble is used (a value from $0 to $f) so two of those can be stored in one byte. The background colour byte from the Koalapainter format file is included for completeness and the code will actually deal with other background colours cleanly despite that not being required in the final release.

One thing that’s missing from the memory map above is where the sprite definitions for the scroller are being stored but there’s a small hole between the end of the packed colour data and where the code starts for a reason; one of the first things the code does is unpack the colour data to $d800 and, once that’s done, the space from $0800 to $09ff is then cleared and used for the sprites so there’s only eight definitions available but, since both scrollers use the same eight sprites, that’s not an issue.

And speaking of the scrollers, there’s that block of unrolled block of code I mentioned previously to split the sprite colours and yes, it’s literally doing that; rather than changing the background colour and having black sprites over the top it’s actually writing one of two values to every sprite colour register on each scanline whilst juggling $d016 to open the side borders. The same block of unrolled code is recycled for the two scrollers, starting one scanline further up the sprites for the upper area so the reversed version of the scrolling message gets the static colours. Finally there’s the eight hundred bytes of scroll text from $10de to $13fe which leaves one byte free before the music starts.

I think that’s everything of note covered, the source code is, I hope, reasonably well documented.

How MD201512 works

Saturday, January 23rd, 2016

To be honest, there’s nothing going on in MD201512 that hasn’t been well documented online previously but we’ll go through it from top to bottom just because we can…

The picture is in AFLI format, that’s high resolution bitmap but with 8,000 bytes of colour RAM rather than the regular 1,000 and a routine which exploits a “feature” of the vertical smooth scroll, forcing the VIC-II to fetch colour data one every scanline instead of once every eighth. The image was drawn by prof4d (who is no doubt wondering why I’m so obsessed with his work since he was the artist behind the picture “borrowed” for MD201509 as well) and originated on the Spectrum. It was chosen primarily for being “wintery” without having anything specifically Christmassy going on and, more importantly, for featuring a snowman.

Conversion was handled by yet another cheap and cheerful, half-completed Windows-based utility which takes SCR files (which are essentially the raw binary of a Spectrum SCREEN$) and reworks the data into a format the C64 can deal with; said converter completely ignores the bright bit of each attribute cell but I’d rather fix that manually. The application of extra colour during conversion to AFLI was reasonably stubtle – by my standards at least – so there’s more PAL blending going on than anything else and those striped areas like the upper part of the sky should appear as solid colours on a real C64.

After the picture is out of the way the code gets to the scrolling message and this is a variation on the main part of MD201509 where the background colour is split several times across each scanline; what makes it different is that the unrolled loop producing those splits deliberately takes sixty four cycles rather than the sixty three available on a PAL scanline so the result is that the splits are “skewed” and produces that nice, almost plasma-like effect.

Finally there’s the sprites in the lower border and these are just moving around horizontally whilst colour registers changed once per scanline, recycling the colour table already in use for the scroller. There’s literally no time left on each scanline despite the “loop” already being unrolled, have a look for a comment saying “split the sprite colours” for this routine and it’s literally just load and store commands using all three registers with no padding between each line; yes it could have been optimised but there was no necessity to do so since it did what I wanted already!