All three collision types are now working! (well, mostly working):

I need to do something about that last one, when you are going to go over an edge. I may just have to extend the physics engine a bit more to make that look good. Thankfully, I have a new tool in my retro development toolkit to make that a lot easier to implement.

I have unit tests with CuTest working with assembler code, so I can write tests for some of the more complicated data transformations (like collision physics) rather than using slow and error-prone hand testing:

As I describe on my wiki page about the subject, you have to set the stack up to around 30000 bytes on the Amiga for the test to run. You also have to include the math library. Get those in place, and you can easily run tests against any symbols exported from your assembler code.

Next is fixing that head konk collision ground slide, then implementing a palette manager which can set Copperlist palettes as well as perform transitions between two palette sets, to allow for color fades in and out and other effects.

I have two of the three collision types working! Well at least the basics of them working:

I also got the tiles background working, though for performance reasons I made the backgrounds 512px wide so it’s easier to do bitwise math for calculations.

Doing both of these things required restructuring a TON of code, and included working out good ways to do unit-ish testing in C of the assembler code I’ve been writing. It’s also helped me focus on ensuring dependencies between areas of the game code are as few and deep as possible.

Next is finishing up the final collision type, the rabbit hitting its head. This will involve the physics necessary to get the rabbit to fall correctly and hit the ground. Then I’ll be doing a few additional frames of animation and moving on to other parts of the game.

This week was about getting a basic level “editor” working, using a combination of a Ruby script with RMagick and an image from LibreSprite:

The level generation works, and I restructured a ton of code to make dynamic level loading work. However, the more complex levels revealed an issue in collision detection that I need to debug.

To make this easier, I’m finally adding some on-screen debugging to the game:

I needed the ability to write text to the info screen anyway. I also need to tweak the copperlist split screen a bit more (that’s the red glitch), but that can come later.

Next will be fixing that collision detection, then reworking the background art to be two 640px images that are tiled rather than one massive 1000px image and fixing the background rendering pipeline.

We have a main menu! It’s very simple, but it also forced me to restructure huge chunks of code in order to allow swapping out the menu and the game code.

This included asset loading code, and this restructuring caused me to find a bug that took a few hours to track down. Symptoms:

• The background would occasionally glitch out when swapping buffers
• The glitching would mostly stop if I didn’t allocate memory for sprites.

What it came down to was this line:

; D0 contains the address to the background art
ADD.W #GAME_SCREEN_LAST_WORD_POSITION,D0

I was adding a value to an address and scoping to word boundaries, and it kinda worked, as long as I wasn’t wrapping around a 64k boundary when adding that value to the address. Changing how memory was allocated, as sprite memory was allocated before screen memory, would change the start address of screen memory and make this “work”.

But I have a menu now! Oh and some more animation! The rabbit will angle up and down depending on vertical velocity, and the jetpack has animation now, too!

Next will be changing up some game behaviors, and then on to some fun bits of the game.

Another week of slow progress, but this is mainly due to some really heavy refactoring work. I wanted to use ptplayer for music, and that required having my code in a ready-to-link format. If I was going to do this, I was going to do it right, and so I restructured all of the code using all of the techniques I use when working with higher level languages:

• proper separation of concerns into deep modules
• “data classes” that enforce structure

My biggest problem holding me back was that MonAm did not like it as all when I gave it linked code:

• I lost all my symbols
• Source code mode was non-existent, though that barely worked for me anyways

Along with all the refactoring, I switched to using BDebug in the Barfly assembler package, and I haven’t looked back. Symbols, source code, proper OS 2.0 windows, full mouse support, command line arguments, and lots and lots of great options.

Along with reworking the game code in this way, I restructured my art compression tool to get more practice. I’ve gotten a lot better at restructing assembler code and figuring out the good places to divide up modules. Once I feel really confident that this is the way to go, I’ll write up an article detailing my approach, if you want to try it out yourself.

Oh, and music playback works!

Not as much progress this week, but some good code cleanups and performance enhancements:

• Spreading out redraw work across multiple frames
• Getting background rendering mostly working
• Precalculating double buffer calculations

Next will be getting the double buffering to happen independently between the front and back planes, which will allow for smooth backgrounds and foregrounds. Then I’ll work on externalizing some more of the game from the code, moving maps to separate files that can be loaded in and adding some other colors to the output.