27 June 2005

I think I've gotten the motion pretty much the way I want it. I've added a template that relates the last heading and the new heading to a horizontal offset to keep the mouse centered around its center of "mass." I also moved the horizontal-facing sprites up the ROM three bytes, to fix the vertical center of mass. Since it has to detect any directional change to perform the horizontal offsets, I use the same branch statement to reset the acceleration.
Today's source Today's binary

22 June 2005

Okay, now the mouse accelerates rather than clomping along at a constant speed, but the momentum is transferrable from one direction to another, so it's kind of nonsensical - you can get a running start in the opposite direction! The other problem is that all the bitmaps are positioned from a common upper-left origin, so if you're moving right and you push the joystick down, the mouse appears to pivot around the end of its tail!
Today's source Today's binary

16 June 2005

The player 0 mouse moves around, but it's a bit herky-jerky. Next up, varying the rate of animation to vary the speed.
Today's source Today's binary

14 June 2005

Time to start animating the mouse and getting this game in play.
Today's source Today's binary

27 May 2005

Wow! Things came together this week. It's looking like a title screen. Fixed the cat's licking-his-chops animation, kept his head from imploding when his eyes blink, and just today added the mouse, which is made up of the player 0 missile (ears), and both player graphics (aligning those is a matter of patience!). Any advice on the black bar on the left?
Today's source Today's binary

23 May 2005

I'm easing my way back into development by finishing up the title screen. It's still a challenge to find all the timing problems, even in a simple display like this. You can see I've cleaned things up a little, but I'm also complicating things. Back in January, I decided it would be nice to add some animation to the cat, who will be eyeing a tasty mouse on the opposite site of the screen. This means that the player graphics sprites need to slide over to the cat's head to form the eyes and chop-licking tongue, then slide back to the other side to make the mouse. HMOVE only bumps them so far, so this takes four scanlines, and I'm having issues (notice that one stray playfield pixel below the bell). I'm not sure if it wouldn't be better to just reposition them altogether! I don't really grok Stella's timing yet, but practice makes perfect...
Today's source Today's binary

24 April 2005

Some kind anonymous soul sent me a patch via the e-mail form on this page, but I couldn't seem to make it work. Whoever you are, thanks for egging me on! I'd love to see your working source - send me your e-mail address if you get a chance.

1 January 2005

I planned this fall to get a playable game working this winter, but I got a little distracted by the title screen. Okay, this should have been easy, but I latched onto a Photoshop design and I haven't been able to let go. The tricky part is that the logo uses both the VDEL 48-pixel-wide graphics trick *and* three colors (the background, blue, and yellow). Rather than using flickering to show more than one color, I decided to draw a black masking graphic over a yellow and blue background. The only problem is that backgrounds repeat and the yellow playfield blocks I need for my yellow bell are too wide to cover with the playfield ball, leaving, interestingly enough, exactly one playfield block's width of yellow. What to do with that? Click to see my solution (mostly working)...
Today's source Today's binary

25 December 2004

Aha, I thought that might be it! Adding the following in front of the title sequence prevents the bitmaps from crossing segment boundaries.

	SEG
	ORG $F100

10 October 2004

Finally finished setting up this web page!

7 September 2004

Thomas Jentsch was talking about masking colors using tables on the Stella list, and since I had this nifty logo, I thought hey, I can make it fade in and out. So I did! It looks pretty good, but it seems to have introduced a timing problem. I can't figure out why this should be, though, since the color changes all occur in the overscan area, and the problem lies within the triple-wide graphics kernel. The nice fade effect has me thinking about making the game start more cinematically, with an animation sequence using the game graphics to tell the background story.
Today's source Today's binary

6 September 2004

I woke up with a logo idea for my game work...my teddy bear (shown on my home page). It's a bit worn and missing an ear, and it's made to stand up on it's "tail" which is really more like a third leg. I drew some designs using Photoshop and typed in two bitmaps: one for the yellow exterior parts, and one for the face, belly, and tips of the limbs, which are white. I thought there should be some clever way in which I could show the white parts and the yellow parts simultaneously, but nothing came to me, so I decided to take a line from Andrew Davie and flicker the colors to get the right effect. Z26 wouldn't show the effect at all well - for some reason it flickers about once a second instead of 30 times a second. Viewing it in Stella, the flickering between the yellow and white bitplanes was really hard on the eyes, though, so I wrote a perl program to merge the bits into a third image that combines them both, so that part of the image never goes completely to black. This reduced the flicker, but made everything too yellow. The solution was to find a complimentary color to the yellow I was using, and use it in the "white" areas to counteract the yellow rather than just lighten it. This works pretty well! Occasionally, you catch a glimpse of the purple color (especially when you flick your eyes around), and of course if you pause during this display it looks nothing like the animated view, so the screenshot shown is faked, but hover over it for a JavaScript simulation. The flicker is visible on my television with the supercharger, but it doesn't look bad. If you didn't know the limitations of the Atari you probably would think it was a stylistic thing; I think it gives it an almost movie-like quality.
Today's source Today's binary
bear.pl

28 August 2004

I turned off the wall code so it wouldn't interfere with my first sprite work. I got the mouse to display and to animate, and I stopped coding when I got a result so funny I had to share it. The animation works, but the code is so clunky that it spills off of one scanline and onto the next on lines where it's drawing the mouse. The result is a spacewarping rodent! Clever little critter...if he devises phasers next, the cat won't stand a chance. (Click image for .avi animation)
Today's source Today's binary

8 August 2004

Saturday night, as I was readying myself to eliminate all of the cute playfield graphics, I realized that I was trying to code a C-like interleaved data structure to describe what should happen in each scanline of the playfield, meaning that all three parts of each scanline (the foreground color, background color, and memory location for the playfield registers) were next to each other for each row, but that I was using code for a parallel structure, where all of the foreground data bytes were together, the backgrounds were together, and the memory locations were together. This was not good! Since I had earlier removed all of my fancy schemes to save ROM memory, I had 192 scanlines worth of data to re-organize, so I wrote a little perl script to re-group each ".byte" line in sets of three.

Et voila! It was almost recognizable as the game board I drew in Photoshop oh so many months ago. The only thing is, the emulator was making a continuous noise and there were two color bars across the screen, one in each of the player colors. I assumed these were the playfield graphics, and checked my math. $91 plus 60 was indeed not $FF or greater, so it couldn't be wrapping around. I was still pretty happy, and went to bed pleased that I'd made more progress. Sunday, I took another look at the problem, tried shifting the memory down in case I was inadvertantly hitting some negative number in the offset (which didn't help, it just changed where the color bars were), and reducing the size of memory getting set, which did help, sorta, except that it then didn't populate all the wall area. So, I stripped out the variable names and posted to AtariAge's Programming forum:

Subject: LDA $80,x where x is, oh, around 60 (decimal)

Hi all,

This is my first post. I've been off by myself re-learning assembly and trying to get a little project going*, and I've run in to this problem. Near the top of my code I have this little initialization loop:

		ldx 60 ; offset starting at the high end
		lda #%11111111
Sterilize	sta $80,x
		dex
		bne Sterilize

The thing is, $80 plus 60 is BC, nowhere near wrapping around to interfere with the registers, yet somehow it is. It's causing noisy noises and setting all the bits in the player graphics registers. Does anyone have a clue for me?

Thank you!

* With help from Andrew Davie's and Kirk Israel's tutorials, Andrew Jacobs' 6502 reference, the Stella Programmer's Reference, and looking at source code from all corners - thanks to you all!

CPUWIZ wrote back a few minutes later:

If that is cut and pasted, it appears that you are reading from memory address 60 and not loading an immediate value into x (ldx #60).

Which was the exact problem. Except I was writing "ldx HOLESSIZE" - changed it to "ldx #HOLESSIZE" - which fixed it! Now there are mostly timing issues to resolve, with some colors getting updated prematurely (middle of the previous scanline), and one or two playfield registers getting updated too late. Of course, from everything I've read, these are the harder problems to solve.
Today's source Today's binary
walldata.pl

1 Aug 2004

I got a much more coherent gameboard by using offsets instead of indirect addressing to retrieve the wall data, but everything's still wrapping around. I took out a lot of code I'm sure I'll have to add back in, but I can't seem to get to a good base state. I decided to spend some time on the score code instead of clawing my face with my fingernails, and I got a decent character set together and solid single-digit score code working. There are 22 cycles of "sleep" between P0 score and P1 score, so maybe that's enough time to merge the tens and ones places together to allow double-digit scores.
Today's source Today's binary

20 June 2004

I've been trying to find good samples of simple playfield source code, and I finally located Christian Bogey's sample TIA Playfield Painter source code, which gave me some insight into how little you can really do in a scanline. It's about twelve LDAs and twelve STAs. My code is way too complicated; especially my scheme for breaking the playing board up into regions of similar color/pattern. Instead of having one set of values for each region, I need to have one set of values for each scanline. 192*3 bytes isn't too much to ask. I hope I can still get away with switching colors and playfield collisions on and off...otherwise I'll probably have to abandon having a checkerboard "floor" altogether.
Today's binary

16 May 2004

Started reworking the game board from the impossible color-change based checkerboard map to a playfield map. Went back to Andrew Davie's tutorial to get a reminder about drawing playfields. Spent a good long time on it but got nothing at all in z26 and a bit of a mess in Stella. I think I'm having addressing problems with my walls, which should have been reset to solid ($ff), and I'm definitely having timing problems.

April 21, 2004