A lot of progress was made quite quickly. The tooling helped to define the missing sprites, and then the room editor allowed the bridge to be laid out from scratch quickly and easily. It's still not done, but it's looking a lot closer to being ready than it ever had before.

Attempting to run the game, however, led to a realisation. The game was slow. There was nothing happening in "the game" at this point, so it had to be the room setup. This has basically changed the next few goals for the project to: profiling and optimisation.

There are two possible options for what might have been the problem here. The first is that it is simply just too many objects, and Tom is stuggling. The other is bus contention Tom and the Motorola 68000 CPU both use the same bus, and if one is accessing data, then the other cannot use it. This means that memory access from one chip can throttle the other.

Thankfully, both of these have solutions which were already planned. I'm still going to investigate, because in part this will give me a better understanding of the hardware, but also, in doing so, I will build up some tools that will help me debug down the road. Building them now when I have a relatively small test case will mean that it should be fairly easy, and they can be improved and refined over time.

If we have a bus contention problem, then the solution is for the GPU to request less data from RAM/ROM and request it only when the CPU doesn't need the bus. Currently the images are stored as 16-bit CRY images. The intention was always to replace them with indexed images. This would not only reduce the size of the image data significantly, but would also allow for some cool image effects. Switching to an indexed image might save as much as 75% of the space (16-bit to 4-bit per pixel) meaning that Tom has to request that much less data.

If, on the other hand, the issue is just the amount of objects that Tom has to process, then the solution is to provide far fewer objects. Initially, prior to the spritesheet setup, the game used a single large image as the background - this had several drawbacks, but the primary one was size - each room required a lot of unique data. The ROM for the game, with just the Peregrine rooms (and no actual game) was already 1.4MB. As the hope is that the game is much, much bigger than that, and the absolute maximum size ROM is 6MB, then that obviously wasn't feasible. Instead, the plan is to bake the sprites into a single (or a few) large object at runtime. This way the ROM can maintain its smaller size, and the game maintains its performance, at the cost of a little pause when the room is loaded in.

I am using "sprite" and "object" interchangeably here - they are pretty much the same thing.

This is perhaps the point where the game will start turning from a quick prototype, with some proof of concept systems, into a game system that can actually produce a working game in the end.

I won't lie, I had hoped to push this can down the road a little bit, so I could at least start making a "vertical slice" scene first. On the other hand, it will be good to tidy up some of the code, and get to know the system better.

Edit: After some quick profiling the next day, it turns out that the issue was actually CPU-side, in the room-scrolling code. I did not think this would be particularly expensive as it "just" adds an offset to the objects, but I guess if this done every frame for ~150 objects, it can cause problems. The solution is still the same: batch the objects together into a larger object. Also perhaps not recalculate the objects if the room hasn't moved…

∗ © 1992, 1993 ATARI Corp