Posts Tagged ‘FLI’

MD201702 (C64)

Tuesday, February 28th, 2017

Well girls and boys, t’s rather late and I’ve spent most of my free time today getting it ready for release so don’t have many words left for a blog post, but MD201702 for the C64 has just been released. It’s another “look at all the pretty FLI colours” routine similar to the one in MD201509, but writing two independent colour values per byte rather than just one. Oh, and there’s some horizontal scroll register splitting on each scanline during the FLI routine which tilts the entire thing simply because that was fun to put in!

The unrolled code updating the FLI colours takes the majority of the processing power, so the copyright symbols swinging back and forth are handled using a similar trick to the swinging logos in MD201602 but using characters… that one might need a “how it works” with more detail at some point but there’s something of a queue forming again, so in the meantime I’ll just point at the Github repository where the sort-of-human-readable source code can be found.

I’ve been thinking a bit more about the Monthly Demo series as a whole and currently like the idea of “organising” it into seasons like television programmes tend to be arranged; that means I can take a break once in a while without worrying about it.

How MD201509 works

Saturday, September 19th, 2015

This post has come a little later than expected, but a few people have asked about it so lets have a quick prod around behind the scenes of MD201509. There are two parts so, unsurprisingly, we’ll start with the intro.

This part is more complex than it initially appears, using cycle-accurate splits for the colour for each letter in the logo; the diagonal tilt comes from a split on each scanline that writes to the horizontal scroll register but it’s not possible to change colours midway across a badline… but that line is where the top bevel of the little bias relief tiles sit so the colour changes wouldn’t be visible anyway! Instead the routine pushes out new colour values six times per scanline for six of the eight lines (since the lower bevel doesn’t need a split either) and sets the colour to grey for the other two.

The same basic technique is used for the colour splits under the scroller and swinging text line, with the routine loading two registers with colour values at the start of each scanline and alternating between writing them across the screen. The badline here just happens to be where both colour gradients are white, so a single change is needed at the start of that line rather than multiple writes during it. Both split routines are unrolled code and built as subroutines so they can be called twice per frame.

In the main part, thirty seven of the colour splits aren’t actually colour splits! The first column is done traditionally by changing the background colour once per scanline with a sprite masking the two character columns to the left of it, but the rest are FLI with a memory- and processor-intensive, unrolled routine rewriting all of the colour data for them once per frame; this routine was what the entire demo was built around so everything else is pushed into the gaps it leaves and there are even a couple of changes for the masking sprites during the bitmap embedded within that chunk of code. A simple bitmap dissolve changes the FLI area back and forth between $55 and $aa (the colour data has a blue gradient value in one nybble and its equivalent from the brown gradient in the other), executing on runtime wherever the interrupts aren’t hogging the processor.

There are a few more colour splits under the scroller which are only slightly different to the ones in the intro and the badline is avoided completely so they’re just seven pixels high. There’s also a hardware sprite at the left side of the scroller because the entire screen is in forty column mode and there would be a character wide gap there without it.

Finally we get to the bitmap filling the majority of the screen. There’s been some talk on MD201509‘s CSDb entry about how it was done that make it seem complicated, but the black parts of the image are just set bits in the bitmap whilst all of the coloured areas are unset. Move some sprites around with the priority set so they’re behind the picture and they’ll only appear over the coloured parts; there are a few more sprites underlaid to add colour where it wasn’t possible to use attributes due to clash, but those are the higher-numbered sprites so the moving ones have priority. The only remaining feature is another routine on runtime that goes through the circles in “random” order, fading them to white and back down to one of the darker colours in the palette, this uses a subroutine for each circle and a jump table to select which is currently being called.

So there we go, the basics of how MD201509 works… if anyone wants to ask questions just fire away and I’ll do my best to answer. If there’s enough interest I might be brave enough to open a Github repository to publicly display my spaghetti-like source code!

Monthly Demo – September 2015

Thursday, September 10th, 2015

After quite a bit of soul searching and chatting to people on IRC, this blog and in person at Play Margate about the idea, the first monthly demo has been completed and released, with the download available from the Cosine website and CSDb. The name is MD201509 (or Monthly Demo – September 2015 to it’s parents) with the “serial number” approach being settled on because coming up with a one-file demo and a decent name at least once a month would have proved too taxing for my already caffeine-addled brain. The main part looks like this…

…and there’s a last minute bonus intro before it as well which even the other members of Cosine hadn’t seen before release because it was started on Monday when I was procrastinating about finishing the main part!

So now I’m sort of committed (or possibly should be committed) to the whole monthly demo concept and we’ll have to wait and see how much of a self-inflicted pain in the backside it becomes! Although I’m not particularly good at planning ahead there are already a couple of ideas milling around for future instalments so fingers crossed…