Fitting Things in Throwing Things Out
I’ve got myself set up and drawing to the screen, along with animating some of the other sprites:
But, look at the edge of the bottom border, where it goes from blue to green. It jumps a pixel on the left:
This means I don’t have my timing right.
It becomes more pronounced when I throw in a P1 sprite with colour, to the point where it knocks out the timing for the whole frame as I move the player around, which becomes apparent on the much less forgiving Gopher2600 emulator:
My kernel already isn’t fitting into the scanlines, and I want to do more. This is where discipline has to come into assembly…
The Atari VCS clock speed allows 78 CPU cycles per scanline of the television. The first 22.6 are in the Horizontal Blank, with the rest running while the picture is being drawn on the screen. Each instruction I write in assembly can take between 2 and 6 cycles to execute, so I need to count cycles for each instruction and plot them out—which you can see in the header image at the top. I hadn’t cared about this yet, because I just wanted to focus on the basics of loading graphics into the right registers in the right order, but now I’m going to have to.
My design for the game involves updating the playfield, which means there will be more to fit in each scanline. Originally I had thought of randomly creating a wall on either side of the playfield to block progress, but that involves an asynchronous playfield, which I am using to render the score counters at the top of the screen, but that means updating the PF registers while the screen is being drawn, and if I’m already not fitting in my player sprites, then even when I clean them up, that’s probably going to be too finniky.
I’ll park my idea for the walls and come back to what I’m doing with the playfield later. Now, I’m going to sort out my kernel.
On each screen I’m going to be randomly loading different things as P1. Some of these are enemies, and some are collectable items. These all have different graphics and animations. Some have colour lookup table, but some are solid. I’m opting at this time to avoid storing a block of solid colour in ROM, but that means it makes rendering them more complex, as now I have to check whether I’m loading a static colour, or a pointer to a lookup table. I’m sacrificing clock-cycles for a smaller ROM. I’ll revisit this later as my game nears completion, and I know whether I have any more space to play with.
To simplify the kernel, I want to use the Horiontal Blank to set all my registers, so that they’re all ready to go before the screen starts drawing; and I’ll use the rest of the time to load and prepare the values needed for the next line. I’m using a 2-line kernel, so I only have to worry about the P0 and P1 graphics independantly.
On paper, I’ve sketched out the new plan, loading the P1 and P0 colour and graphics and setting them aside, then straight after WSYNC, transferring them to the TIA registers. This fits them nicely inside the horizontal blank, and still leaves me plenty of time during the scanline for other things. I am sacrificing 4 more bytes of RAM to do this, but I still have plenty of that at this stage.
Success. Nice and stable, no more offset pixels.
