Starting the tech experiments...

It's been over a week since Doc Cosmos was released and the community response has been amazing. A huge thanks to everyone who downloaded and donated. And if you haven't played it already go grab it here: There will be a bug fix update coming for the original game before the RGCD competition deadline so feel free to feedback to me as everything is being noted and I'll be fixing and updating everything I can fit in for the final patch release.

There were many things I wanted to do in the original game that simply would not fit into 16K, and a sequel was always in the back of my mind. So this past week I have spent some time thinking about roughly what I want to do and decided to share the process from beginning to end in a development log. Welcome to the first instalment!

Week 1 - Scrolling fun!

The main thing I wanted to do in this version is to move from the flick screen approach to a 8 direction scrolled map (I want Doc 2 to feel like the love child of Turrican, Montezuma's Revenge and Rick Dangerous). I also want  per character colour, so this is no simple task. It's also important to retain the timeline effect as that's kind of Docs unique gimmick.


First task was to choose a tile size. In the original game I used 2x2 tiles but while this gives a lot of opportunity to vary the level design it takes a lot of memory even with compression to store the map (the 47 original screens took up about 4500 bytes compressed). I want the sequel maps to be quite large and so I settled on 4x4 tiles. My initial map size is 128x64 tiles which means the map and tiles will take up a total of 12k excluding colour maps and enemy/sprite information. This equates to over 160 screens per level!!!


The scrolling code has posed a number of technical challenges. First of all scrolling 20 lines of full colour tile map in 8 directions is very CPU intensive. So in order to achieve this the map and colour shifts are split over 4 frames, meaning the map can scroll 2 pixels per frame in any direction. I think eventually I will have the screen "catch up" to the player to create a more pleasant camera motion. Secondly shifting colour RAM has to be split over two frames with one of the frames starting midway down the screen, and to combine this with a moving  time line effect and a sprite multiplexer means I'm going to need something to dynamically assign and sort IRQ routines.

So the end result is that after just over a week I have the first draft of my scrolling code working along with a dynamic IRQ manager. The IRQ manager allows me to add a split anywhere on the screen and have it sorted into a list to be triggered in the correct order. Once the sprite multiplexer goes in I'll iron out the few remaining timing glitches, but so far I'm pretty pleased with the results, there's plenty of raster time left over to do the myriad of things I have planned. 

First tests

I threw together a quick HUD design to test out the new area which is four lines compared to the originals two. Its absolutely going to change but needed to put something in as the emptiness was getting to me. I also took the character set from the original and made some simple 4x4 tiles to test out the scroller and make sure the colour RAM is working correctly. 

With all this in place I ripped out the original timeline effect code and put it into the IRQ manager after switching it to a single sweep from bottom to top instead of two from the middle out (I think this will help keep the sort time for the raster splits down, especially once multiplexing is in the mix)

It's not much to look at, but here's the fruits of my labour:

Next Up

Next task is to start adding the player sprite into the mix and start adding his controls in. I also want to start creating a first level and thinking about the overall story so  I can start developing a theme. Lots to do!

Until next time!

Leave a comment

Log in with to leave a comment.