Nukey Shay, on Mon Aug 30, 2010 9:48 PM, said:
I disagree...everything is easier when you throw unlimited resources at it.
I'm not sure who/what you're disagreeing with, since you didn't quote, but on the chance that it was my comment about why 10 aliens spaced closely won't work, I'd like to expand on my reply. I was referring to the following "trick":
LDY line
LDA (graphicspointer),Y
STA GRP0
STA GRP1
LDY #0
STA RESP0
STA RESP1
STA RESP0
STA RESP1
STA RESP0
STA RESP1
STA RESP0
STA RESP1
STA RESP0
STA RESP1
STA RESP0
STA RESP1
STY GRP0
STY GRP1
This gives you 10 aliens, with just 1 color clock between them. If you leave off the two STY GRPx instructions, you get 12 aliens, but the last 2 aren't spaced the same as the others-- there's -1 color clock between the 10th and 11th aliens (i.e., they overlap on 1 color clock), then the 11th and 12th aliens have 1 color clock between them, as the others do. So to get 10 evenly-spaced aliens, you need to do 12 RESPxs, alternating between RESP0 and RESP1. Since the sprites are drawn 6-pixels wide to allow for the appearance of smooth movement left and right, there's really 3 blank color clocks between each alien.
Another option would be to do it this way:
LDY line
LDA (graphicspointer),Y
STA GRP0
STA GRP1
STA.a RESP0
STA.a RESP1
STA.a RESP0
STA.a RESP1
STA.a RESP0
STA.a RESP1
STA.a RESP0
STA.a RESP1
STA.a RESP0
STA.a RESP1
This gives you 10 evenly-spaced aliens without having to do 2 extra RESPxs and without having to erase the last (extra) 2 aliens. But now there's 4 color clocks between each sprite, or 6 blank color clocks. That's not as tightly-spaced as the first method, but it's still tighter than the method used in Galaxian.
By the way, the only reason I'm talking about 10 columns of aliens is because that's how many I see on screenshots of the arcade game.

So to get closest to the arcade game, it would be cool if we could draw 10 aliens per row, and have them be as tightly spaced as possible, which would be the first method rather than the second one.
Unfortunately, the first method doesn't have a good way to turn off specific aliens in a given row. I was thinking you could do a store to a dummy zero-page location, to skip a RESPx, but that throws a huge monkey wrench in the spacing.
On the other hand, the second method (STA.a RESPx) does keep its equal spacing if you do a dummy STA abs or STA.a zp instruction in place of a STA.a RESPx instruction. But then the 10 aliens take up so much space across the line that there's not much room for them to move back and forth.

Still, you could do 8 aliens and they'd be in a tighter formation than the 2600 version, so that's a good thing.
To pull this off, you'd need multiple versions of a scan line, because you'd need a different version for each possible combination of on-off aliens. With 10 aliens, that would be 2^10 = 1024 combinations-- not out of the question if you've got enough ROM. With 8 aliens, it would be only 256 combinations. Not only would that take less ROM, but the aliens would have more room to go back and forth.
Of course, I'm talking about just 3 positions of the aliens-- %11111100, %01111110, or 111111. So you'd also still need multiple copies of the kernel to get the aliens to move across all possible positions. And for each copy of the kernel, you'd need 256 versions of a scan line (to handle all on-off combinations for 8 aliens per line). That's certainly still doable, given enough ROM. If I were doing it, I'd try to have subroutines for the different lines, so I could just JSR to whichever version were needed to get the desired on-off sequence of aliens on any given row.
*But* that's where the other wrinkle comes in. To get an alien to move out of formation and dive, you'd need to use flickering, since you'll need to use either player0 or player1 (depending on which alien is moving out of formation), and you're already using both players to draw the aliens in the formation. So on every line where you've got aliens in formation *and* a diving alien, you'll need to flicker either player0 or player1. Personally, I don't mind flicker, so I could live with that-- although it might look kind of odd to be flickering some of the aliens on that row, but not others.
The method that 2600 Galaxian uses-- employing just one player for the aliens in formation-- is actually pretty neat, because it allows the aliens in formation to be free of flicker, and it's easy to turn specific aliens on or off (by changing NUSIZx), although the spacing between the columns is a bit uneven, and-- more to Derek's point-- the columns aren't as tightly spaced as might otherwise be desired.
If you can use the STA.a RESP0, STA.a RESP1 method to get a tighter spacing, then go for it! Like I said, I can live with flicker. But I am bummed out that the STA RESP0, STA RESP1 method isn't feasible, because it would be awesome to have 10 aliens separated by only 3 blank color clocks-- if only there were a way to turn individual aliens on and off without screwing up the spacing.
As for the orange border, I don't see why the diving aliens need to fly behind anything, since they could just be turned off when they reach a certain distance from the edge of the screen. As it is, the border doesn't even go all the way to the edge. Sure, you've got the HMOVE lines on the left side, so having 8 black color clocks at both edges keeps things even. But the RESPx method doesn't let you move all the way to the left edge, or even very close-- the closest you can get is 19 color clocks from the left edge. Without the orange border, it's pretty obvious that the aliens are turning around while they're still a goodly distance from the edge. By having a border that's 8 color clocks wide, and set 8 color clocks from the edge, the aliens can get to within 3 color clocks from the border before they have to turn around, which sort of distracts you from the fact that they can't go all the way to the edge. I'm not talking about whether the playfield/border color is orange, purple, green, or white-- obviously, if you want the ball to be a particular color, then the border must be the same color, since there isn't enough time during the loop to change COLUPF, since the program is so busy changing NUSIZ0 and strobing RESP0 multiple times on each line. But since the diving aliens can be easily turned off when they reach a certain position, instead of having them fly behind a border-- in fact, their shape could be "turned off" one pixel column at a time to make it look like they're gradually disappearing offscreen instead of disappearing all at once or flying behind a border-- it kind of makes the border unnecessary, except the border does make it seem like the aliens are getting closer to the sides than if the border weren't there. So I suspect there were multiple reasons for the border, one of them being the reason I suggested, and another certainly being that it's easier to have the aliens fly behind the border instead of having to make them disappear a pixel column at a time.
By the way, I was using Stella's debugger to step through the game a frame at a time, and I noticed that the flickering when two diving aliens overlap each other doesn't seem very efficient. Namely, one alien will be on for multiple frames, then the other alien will be on for multiple frames, instead of flickering between them at a steady 30Hz.
Michael