SpiceWare's Blog

And another two minor ones:

1. after you lost a life, the ship is pointing in a random position. I don't know how the arcade plays here, but Asteroids 2600 starts always with the ship pointing up.

2. when you switch the shield display to flickering between vector and non-vector, I suggest using this at the start of a new life too

I'd been thinking of decreasing the shields to 2 seconds instead of 3, will do some tests with that today. FYI - the kids variation has unlimited shields.

 

1. I'll take a look at that. Part of the reason is for the 2 player games. Originally respawn would occur in a random location and direction because of 2 player simultaneous games, it was modified to always occurs in the middle for 1 player at a time games and randomly for the simultaneous games.

 

2. I think we're going to have to prioritize your suggestions that involved additional code as there most likely won't be room for all of them.

Definitely! Personally I think bugs should come 1st, in game changes 2nd and menu stuff 3rd and last.

 

Not sure how much space optimizations can help getting as far as possible, but I guess they only give a small fraction of what would be required for everything.

 

Also you should set a deadline to any changes (except bug fixing), which leaves enough time for final testing and fixing.

 

BTW: Two second shields is probably still to long. IMO it would be good enough if a small or medium rock can pass. But not a large one.

Technically, the deadline for non-bug-fix changes was when I posted the first Release Candidate on October 2nd.

 

I considered the shield regen a bug fix - it was an oversight on my part because it should have been that way to begin with. Menu tweaks can be considered "cosmetic bugs", and minor changes to constants like the one used for the shield timer are OK as well.

 

Adding a "end of shields" indictor, either visually or aurally, is a neat idea I hadn't thought of and if either can be added I'll do it. I doubt any other addition from the "wish list" will occur, though the change to the menu option CONTROL would be really nice as it'll make that feature less confusing.

Oh oh, didn't realize I was THAT late.

 

I noticed the font changes. Like the new Y, 5 and °, but leave the final verdict to Nathan and you.

(BTW: I know I am annoying, but IMO the - in CO-OP should be one pixel smaller to have a better visual gap between label and option. And then it also matches the one in Magna-Mines )

 

Please don't forget to increase the time before menu when the game is over. Assuming this is only a constant correction.

yeah, you did jump in rather late

 

Good call on CO-OP, it's been changed.

 

I have to change the timer logic to countdown every other frame, adding an if (FRAME & 1) will take care of it. That code change will cost 12 bytes - it's set up, but commented out until I know if we'll have room for it.

12 bytes? Looks like our good old Atari 2600 still beats the most efficient modern CPU by 7 bytes!

Two very minor comments on the menu:

1. instead of "Players 2 Jx1" or "Players 2 Jx2", why not do "Players 2 J" or "Players "2 J J" (J = joystick symbol). IMO that might look better.

2. Control option belongs logically directly below Players option

1 - I'll let Nathan make the call

2 - done. Thankfully, due to the way I set up the routines, all I needed to do was shift data stream block that started with MENU_CONTROL_ID = (* - MenuOptionsDatastream) / 20 to be after the Players block and recompile. All the C code automatically adjusts. Besides being more logical, it also gives it a better look with the "curve" between the option names and values (screenshot added to blog entry).

Found a small bug:

 

A twin Magna-Mine got stuck at the very bottom of the screen. For several seconds you couldn't see anything, then a short orange bottom line flicker. Then this repeated at least three times. Eventually the mine decided for one direction and moved up.

Hmm - the closest path routine can decide the best route to take is to wrap around the screen border. It probably ended up at just the right distance to make the closest path alternate between upward and downward as it turned.

 

I've jotted down a note to take a look. That'll be a tricky one to recreate.

Another small bug: in the "normal" 2 player games, the right player gets initially 4 lives.

Both players get 4 ships, what's shown is reserve lives.

 

Player 1's first ship is already onscreen, so he only has 3 in reserve.

 

Player 2's reserve will decrement to 3 as soon as his first ship appears on screen.

Both players get 4 ships, what's shown is reserve lives.

 

Player 1's first ship is already onscreen, so he only has 3 in reserve.

 

Player 2's reserve will decrement to 3 as soon as his first ship appears on screen.

Ah, makes perfect sense now.

A twin Magna-Mine got stuck at the very bottom of the screen.

I've seen this a couple times since then. I was looking over the code during my lunch break and think I figured it out. ScreenWrapSprite() adds a 16 scan line wrap-zone when dealing with the Y value. DirectionToShip() did not consider the wrap-zone.

 

This difference would cause the MMs to get confused about the closest path. I've added 16 to the DirectionToShip() logic, which will hopefully fix the problem.