The dragon-related logic for my untitled Atari game has been greatly improved since last time. In addition to color and size/number, each dragon (or set of dragons) has its own direction, speed, and animation rate now. Progress is still going strong, and I’ve only used up about 1 KB of ROM space so far.
You’ll notice many more black lines on the left hand side of the screen. These are display artifacts resulting from the re-positioning of the same sprite to draw what looks like multiple moving objects on the screen and are, as far as I know, unavoidable (many commercial games from back in the day had the black lines on the left side of the screen, too).
I also did a little trick to fix the coloring on the ballista. In the previous videos you may notice that the central body of the ballista is black on the same horizontal rows where the ballista’s black drawstring is drawn. This is due to the fact that a “sprite” (a term for an animated onscreen graphic) can only change colors between lines, not within a line.
To counter this restriction, I used a second sprite, colored it brown, and made it so that it will always draw over the center of the ballista (adjusting its sized based on the ballista’s current frame of animation when firing). This gives the illusion of a two-color sprite.
M0 Sprite over P1 Sprite
I’ve been teaching myself various other little tricks in order to get things to behave the way I want — mostly dealing with Boolean logic. It’s been challenging finding answers to certain problems; most of the Atari 2600 programming help online consists of either examples that are just too simple or code that is just not very readable due to both lack of code comments (a major problem with most code people share online) and greatly abbreviated labels and identifiers and such. The most common resources I use are a 6502 opcode reference document and the Stella Programmer’s Guide.
The act of programming in 6502 assembly code is becoming more and more “automatic” for me now. I find myself writing scraps of basic 6502 assembly code from memory now onto paper and whatnot while brainstorming or while trying to figure out a solution to some problem. Stuff like this is much more naturally readable to me now:
Now I have to watch myself so that I don’t write too much code in my program without any proper comments explaining what I am doing and why. When you first start learning a programming language, you spend most of your time thinking about how to write the language itself. When you’re very familiar with a programming language, you spend more of your time thinking about what your program should do, and the writing of the code becomes almost automatic. If you’re careless (or undisciplined) this often leads to uncommented code.
Anyway, with the repeated refinement I’ve been doing on my program’s code, it looks almost clean enough to share publicly. I might still wait a while before I make it available, though. I want to make sure there are no misleading comments left over from code changes, and that the reasoning behind everything is clearly laid out.