Okay, Campbell’s, I get it: your “Chunky” brand soup eats like a meal. I do not contest this.
I finished the last major component of my snowtrooper costume the other day. The belt pouches are finally done.
I had tried to sew them myself, but the two small sewing machines I had were nowhere near powerful enough to push through the fabric I used, so, as with the duster, my mom helped me out there. I did attach the belt loops by hand, though. Sewing through four layers of duck cloth by hand is a bit irritating, but at least I didn’t break any needles like I did with the velcro I attached to other parts of the costume.
At this point, I have all the armor pieces weathered. I only really need to finish weathering the duster, pants, and now these pouches. I may still want to improve on the straps I put together to hold up the backpack, but that’ll pretty much be it for the cosmetics of the costume itself and it’ll be ready for some proper photos.
I’ll still be adding small cooling fans inside the helmet and a voice modulator in the chest. I’ve also been considering creating some sort of cooling vest. It gets pretty warm wearing that costume indoors for any length of time (especially under the helmet).
I’m also thinking of maybe coming up with some sort of external microphone & earbuds solution for making it easier to hear from inside the helmet. You’re half-blind and half-deaf with that thing on.
I’m sure they’ll get me one of these days…
I’ve managed to get some more stuff going on in the Atari 2600 game I’m working on. The following video demonstrates the ability for the program to display something new: fireballs.
There’s still a lot of work to be done, yet. I’m going to see if I can get more than one set of fireballs on screen at the same time.
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.
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:
lda SWCHB lsr bcs NotReset jsr Reset lda #%10000000 sta GameState rts
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.
Got some dragons flying in my Atari 2600 game:
(It looks a lot smoother in the emulator; I recorded this at 1/2 the normal frame rate in order to make the animation file smaller).
Currently, all the dragons are sharing much of the same information, like X-coordinate, animation frame, direction, etc. Next, I’m going to have to modify the program so that each horizontal “layer” of the sky can have its own, independent dragon.
Once all the dragon independence is programmed, then I’ll look at tightening up the code a bit — there are still some minor graphical glitches with the dragons I want to address.
I’ve added multi-coloring and animation to the ballista now.
There are some minor glitches still with the drawing of the arrow as it’s firing, but it’s hardly noticeable. I may also try to get the central body of the ballista to remain the lighter brown color instead of being the same color as the draw string, but that will require the manipulation of a second sprite, and I may need those resources for more important game features.
There’s room to optimize the code for all this, but I’ll worry about that later if ROM space ever becomes an issue.
I think it’s time to start adding dragons…