Galaxian - Expanded

[Nukey Shay]

Kevinmos3 sort of got too busy in RL...and as some of you are aware, I'm not too comfortable hacking in the dark. There's only a couple of remaining issues (neither of them serious), so I'm setting this adrift. I've got no space left to correct them anyway without removing something else.

 

The goal was to update the graphics...but unfortunately, the program doesn't like it's sprites to be using anything but 6 pixels (because it uses the reflect register to handle some of the fine positioning. This is my first venture into the realm of multiple RESP0's, so give a yell if I broke something.

 

I started by hacking the color stored to the player's ship. This lead to one of the bugs that remains unfinished - occasionally, an alien will flash as it charges the ship. This glitch is tied to how the color change was originally shared with attacking flagships (because the ship and flagship sprites used the same one)...so I don't have a good solution to it.

 

Anyway, all the colors have been extended...aliens on the upper rows can have each of their scanlines be a unique color. This changes to the default flat colors as they charge the ship - not enough cycle time to deal with that problem (tho maybe with redundancy).

 

The other issue is the flagships. I pretty much had to use 7 pixels there to make them look decent. This has the side-effect of wobbling slightly in 2/6 of the horizontal positions. Not a big deal IMO...and it makes avoiding hitting them a little more challenging (i.e. when they are sitting up top and not worth much).

 

The game uses the original's point scoring and control. Use select to start on any level up to 9 and the left difficulty to make the aliens a bit more aggressive. You can now select your torpedo's width using the right difficulty switch - and you can use a joystick plugged into either port. In addition, the game allows you to hold the stick sideways to control left and right movement via down and up (perfect if you want your right thumb squarely on the trigger).

 

Pressing the color/B&W switch allows you to turn invisible - effectively pausing the game if you need to. The routine should be 7800-compatable, but there may be a hiccup if you alter them as the game goes though it's "glitch" session. Pressing the joystick button allows you to jump right into the action if you don't want to watch that mess.

 

 

Open to suggestion - particularly for any ideas of how to get rid of that stupid reflect and use proper h.positioning!

 

 

 

EDIT: 3rd corrected version 12/14

Galaxian-Expanded.zip

Edited December 15, 2010 by Nukey Shay

[Nukey Shay]

A lot more broken than I figured. The enemies do NOT become more aggressive per level, and the left-handed routine does NOT work correctly. There's also a timer overrun that has a chance of appearing on higher levels. Got to go back to a previous build and find out where it's going wrong.

 

I knew going public was a good idea

[Bentley Bear!]

Bah, even with a few bugs this more "arcade-like" version of Galaxian rocks hard and looks awesome Nukey! Much thanks to you and Kevinmos3! I wish I could help you guys, but programming is not my bag sadly...

[Nukey Shay]

Easy to fix the ones I overlooked...I just need to pick a different memory location for the added functions that doesn't collide with the original variables.

[Lord Helmet]

Awesome. I can't wait to play this tonight.

[Nukey Shay]

Corrected version posted up top. Rethinking some of the routines left me with a little extra space, and the program will track the console switches all the way from powerup. I still need to know if it works OK on the 7800 if anybody's got the means to try it out.

 

NOTE: the startup sounds a little different...I decided that ram byte was better spent tracking everything I added (because it's the only one that I know is untouched by the rest of the program's subroutines)...so I gave up trying to merge it's variables for another byte. The score table will also precede the original attract screen during it's loop as a result.

 

Post any glitches, suggestions, etc...particularly if playing at higher levels (since I suck pretty bad at this game to check).

[nathanallan]

Nice, I like the startup screen. Also I couldn't program myself out of a paper bag. Well, maybe a paper one. Plastic, forget it.

 

Nice! I am having fun playing it.

[accousticguitar]

I played a couple rounds on a Kroc cart and a 7800. Seems to work fine. That's a nice startup sequence, and the aliens look great!

[NE146]

Definitely going to check this out when I get back.. Nukey r0x j00 s0x

[TrekMD]

Very nice work! Thanks for sharing this Nukey!

[Nukey Shay]

Scanline jitter is still there Need to track that down.

[Nukey Shay]

Attempt:

I moved some branching off page breaks and cleaned up a couple things. I'm not seeing the scanline jitter for charging aliens now...and escaping out of the point advancement screen no longer alters the count (this was most noticable in the PAL build). With luck, this is the last fix.

 

Posted up top.

[Nukey Shay]

In the arcade game...how far are charging aliens allowed to go beyond the side borders? In this hack, not at all since I got rid of the side PF (which shares the ball color). The port originally allowed it to a small amount when moving into the borders, but that range can be extended pretty easily...just skip repositioning and drawing if moving into the border area.

 

I'm particularly interested in this issue because of the goofy way that bordering aliens will leave the formation and "chicken out" immediately instead of continuing the bombing run.

 

BTW if allowed, it actually makes for shorter code (because the game would no longer need to check for boundries...just skip the sprite if the horizontal position is negative (i.e. greater than $7F or less than $00). Makes them look like they are actually trying to do something instead of "chickening out" and returning to the formation.

Edited August 29, 2010 by Nukey Shay

[Nukey Shay]

Dang...I found out how to do 8 aliens on a line (to correspond with the 8 bits in each ram location)...but since that adds 11 cycles, it would mean giving up loading new colors for every scanline - or, expanding the binary to 16k and unrolling the display loops. Should I go for a 16k binary?

[nems]

A 16k binary sounds good to me.

[TrekMD]

If 16K is what you feel you need to make an even better Galaxian, go for it!

[Derek]

I would have been happy if you had released a version that simply removed that god damn orange border. What was the point of that? Why did Atari add that when it had nothing to do with the original game? When I first got this cart (as part of a big boxload from O'Shea's, back when they first started clearing out and had copies of everything they had listed, I bought one of each, wish I had bought two of each.) Anyway, I turned it on and thought it had a nice attract screen, then I hit start. No background stars and and a pointless and ugly orange border. Why?

 

I hate to say anything critical as I scraped through programming back in grade 10 in 1987. I have never endured anything more frustrating as I do not think like a computer, and if I wasn't a guy I would have burst into tears and run out of the room. Instead I did the guy thing and got angry. I managed to get a D minus for the year, but I hated every second of the class and dreaded going each day as it was soooo frustrating. That said, I am envious of anyone who even remotely understands what is going on inside a game cartridge and can make changes to improve it $P, $G geez, it makes me stressed to even think of all that stuff. I didn't get it then, barely passed the required course. That really annoyed me, it was required. If I didn't pass it I had to take it again in Grade 11, then there was the risk of not having enough credits to get the fuck out of high school in three years and having to come back in 1990 to get that one credit. It was so close. I passed with 62%. Small wonder I ever touched a computer again, having one come so very close to me having to endure a fourth year of high school.

 

So, your improvements on 2600 Galaxian to me are very impressive, perhaps you could dumb down an answer as to why the rows of attackers are so far apart as compared to the arcade game where they are close, and a fired missile might have hit something in another row instead of causing a delay as your fire drifted up that large gap between rows before you could fire again.

 

Perhaps someone can work on the 2600 ms. pac man game and get rid of the ghost flicker, use more K and have more sounds possible at the same time, change the light blue background so it is not 95% the same color as the ghosts during the time you can eat them?! Of if someone would enjoy playing a game that is FUBAR, I could take another crack at programming and release my efforts towards improving ms. pac man. Mmmmm, bad idea.

[johnny_boy]

I do appreciate the vast visual improvements, but I personally feel the flicker caused seemingly by the player's multi-colored sprite is too distracting for its own good. I'd personally prefer a plain grey body, perhaps keeping the red-tipped nacelles.

 

Still, a stellar effort. I amused myself comparing this version with the original and the "Galaxian Arcade" hack for a short while. Yours definitely comes on top.

[accousticguitar]

If you want ghosts that don't flicker, check out Debro's Pac-Man 4K.

[SeaGtGruff]

I would have been happy if you had released a version that simply removed that god damn orange border. What was the point of that? Why did Atari add that when it had nothing to do with the original game?

I suspect that the orange border was to distract you from realizing that the aliens could only move so far to the left and right-- they can't go all the way to the edge of the screen (at least on the left side). The border seems to be positioned far enough in from the left and right edges that the aliens can go all the way to the border (I think) before having to turn and go back the other way.

 

perhaps you could dumb down an answer as to why the rows of attackers are so far apart as compared to the arcade game where they are close, and a fired missile might have hit something in another row instead of causing a delay as your fire drifted up that large gap between rows before you could fire again.

The quickest and simplest answer is that it's a result of what the programmer did to work around the 2600's limitations. It's actually possible to get 10 columns of aliens that are spaced much closer together, but there are technical reasons why that wouldn't have worked here-- or (1) would have added a lot of flicker whenever an alien broke out of formation to dive at the player, and (2) would have required a huge amount of extra code to handle all the different combinations.

 

Michael

[NE146]

I would have been happy if you had released a version that simply removed that god damn orange border.

 

Already been done for a while now. http://www.atariage.com/hack_page.html?SystemID=2600&SoftwareHackID=57

[Nukey Shay]

I disagree...everything is easier when you throw unlimited resources at it. Had they used a 16k version, an entire bank of space could have been used to handle just the upper portion of the screen (which is what I'm trying). The display loop has been reduced to only a page long. They used 6 dedicated ones based on which pixel location to begin drawing at - I combined them all. Unrolling that so it's no longer a loop uses about 2k...or roughly the same amount of space they squandered by using dedicated loops for each of the 6 positions

 

As far as the orange border goes, that was done to give the ball sprite color AND provide borders that the alien sprites could fly "behind". Can't use M0, because the missile recieves the same number of sprite copies that the 8-bit sprites do. So you could either use Space Invaders' method of reusing the same sprite for all missiles, or divide the screen into sections that handle the sprites differently...such as using M0 down below the rows (with M1 belonging to the aliens), and switching to M1 among the rows (because the convoy aliens don't shoot). That keeps the playfield available to draw the borders for chargers to hide behind and set to color black so it can't be seen.

 

All that sharing and reusing would cost the 2600 its most valuable resource, tho...which is native RAM. Keeping the missiles seperate means that you can just look at the hardware collision registers for hits. If sharing is going on, that would cost ram to keep track of who is hitting who.

 

I'm still having problems figuring out what is shared and when...so that some of this ram can be reclaimed.

[Nukey Shay]

I do appreciate the vast visual improvements, but I personally feel the flicker caused seemingly by the player's multi-colored sprite is too distracting for its own good. I'd personally prefer a plain grey body, perhaps keeping the red-tipped nacelles.

That is actually easier to do - just change colors and not change sprites. However, 30hz flicker is a simple way to double the sprite colors (to produce the red line down the middle). I'm looking into recoloring and repositioning the ball sprite to do that job. The problem is seperating the ship display from higher bands - that is where the white flash sometimes present for charging aliens comes from. The same routine draws sprite-copied aliens (usually the red escorts) and the player's ship. The branch that I stuck in there works most of the time, but I have no idea why it fails (and produces white-flashing aliens) yet.

[SeaGtGruff]

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

[keitaro]

The Score Advance Table is awesome. I love 2600 Galaxian, but the new features makes it better.

 

The new sprites for "boss aliens" are great too, but how about define the sprites for "standard aliens" like the used in the hack mentioned before? (http://www.atariage.com/hack_page.html?SystemID=2600&SoftwareHackID=57). There are more accurate to the Arcade version.