Limits of Scale
As someone who has been taught Software Engineering, there is something both refreshing and frightening about assembly programming on the Atari. On the one hand, all of the standard rules about abstraction, modularity, generic data structures and exception handling go out of the window as there is simply not enough memory or cycles. On the other hand, the resulting code ends up becoming increasingly complex and tangled in the quest for space and efficiency!My PoP project is now the largest assembly program that I have ever written, much larger already than Hunchy II. However, I am also finding it increasingly difficult to make changes to the game. The problem is that the code is strewn with magic numbers and bits, and changing one part of the code can have unforseen consequences in another part. Sometimes, even changing the length of a particular bit of code can cause breakage due to memory alignment problems. The result is that updates to the code are becoming slower and slower. I am also rapidly running out of space for the code - the 6K provided by the Supercharger doesn't go all that far in a game like this.Anyway, I don't want to be too negative as things are not desperate yet! It is just that I can see a big code optimisation and reshuffling phase will be required soon if the game is going to progress much further. The latest update to PoP is attached to this blog entry. The new features this time are that the falling tiles now disappear when you step on them (after a short delay), and the switch in the final room now opens the door (see image below). I haven't yet fixed the collision detection with the doors, but I have a possible solution worked out.Up to now I have been modelling the game around the SNES version (probably the best conversion). However, this is not the ideal version to use as it contains extra levels and graphics not found in the other conversions. I have now aquired the Gameboy Color version of the game (thanks to eBay) and I will be using this instead. The Gameboy version is probably the least advanced, and is a much closer fit to the capabilities of the Atari. The switch to the Gameboy version is already yielding some useful clues. It contains a possible solution to the falling tile problem that I described last time. Instead of showing the tiles falling the whole way down the screen, the falling tile is shown briefly at a fixed position under the original, and then removed entirely. This effect shows that the tile is falling without requiring any complex animation, and it also appears reasonably convincing. I am planning to implement this in my next release to see how it looks - I just need to decide if I want to use the sprites, missiles, ball, or PF. As discussed previously, all of these have advantages and disadvantages, and I'm not yet clear which will be the best compromise.ChrisP.S. Looking back at my earlier "Multi-Tasking" entry it appears that some good progress has been made, although it doesn't always feel like it! I have basically accomplished tasks 1,2,4,5,6,7, and 10. The big issues remaining now are really just the animations and guard movements, but I know these are going to be tough!
15 Comments
Recommended Comments