SpiceWare's Blog

Sorry, for coming that late, but can you add some feedback for the shield status? E.g. different decreasing or increasing pitch while the shield is enabled. So that you can judge when the ship will explode.

Nice idea - though after the updates for RC 4 I don't have much room left:

 

14 - bank 0-4 (ARM)

1, 1, 0, 10 - bank 5

3 - display data

3 - frequency data

 

I think I know how to do it economically though, will take a look at it after work. If you spot any more space savings in bank 5 that'll make it more likely that I can squeeze it in.

This is an uneducated question from someone who knows nothing.

 

Isn't there supposed to be extra eeprom on the Harmony? Is there any way to parcel some things out on that space?

I ended up taking a look at it while I was on break and the initial shield frequency manipulation routine increased the program by 68 bytes, way more than I was expecting for what little code I added. I suspect it negated some compiler optimizations of the original code.

 

After writing it, I realized it wasn't going to work correctly because it didn't track which player the sound effect was for. And on top of that, because of how the sound effect routines work, in 2 player games if both players triggered shields only 1 instance of the shields sound effect would be heard so 1 player would be at a disadvantage.

 

As such, I don't foresee this happening.

 

 

 

The game cartridges are going to be using Melody boards. Extra eeprom space can be added to it, but that's not a last-minute decision to make.

I will look into the 6502 code again to find some more space.

Assuming P0RepoExtra can be called at any time:

P0EarlyHM68: ; 5 20
 dec Sleep5 ; 5 22
P0EarlyHM63: ; 5 20
 dec Sleep5 ; 5 22
P0EarlyHM58: ; 5 20
 dec Sleep5 ; 5 22
P0EarlyHM53: ; 5 20
 jsr P0RepoExtra ;27 47
 SLEEP 3 ; 3 50
 sta RESP0 ; 3 68
 jmp KernelLoop ; 3 71

P0EarlyHM73: ; 5 20
 jsr P0RepoExtra ;27 47
 jsr WasteTime23
 sta RESP0 ; 3 73
 jmp KernelLoopNoWSYNC ; 3 76

P0RepoExtra:
 ;jsr P0RepoExtra ; 6 6 the call to get here
 lda #<DS_HMP1 ; 2 8
 sta HMP1 ; 3 11
 lax DS_MISSILE ; 4 15
 asl ; 2 17
 tay ; 2 19
 lda #<DS_GRP0 ; 2 21
 rts ; 6 27

Nice, that freed up 19 bytes.

 

I just did a fix in the ARM code for 2 player mode - a friend was over tonight and we discovered if player 1 hit their shields that player 2's ship also color cycled, even though their shields weren't active. The fix involved moving a variable assignment from outside the loop to inside the loop, and it surprisingly freed up 16 bytes. No code was added or removed, just moved.

 

30 - banks 0-4

1, 1, 19, 10 - bank 5

3 - Display Data

3 - Frequency Data

After writing it, I realized it wasn't going to work correctly because it didn't track which player the sound effect was for. And on top of that, because of how the sound effect routines work, in 2 player games if both players triggered shields only 1 instance of the shields sound effect would be heard so 1 player would be at a disadvantage.

 

As such, I don't foresee this happening.

I understand the problem. But you could disable the special sound in 2 player mode. Most people will mainly play single player anyway. Assuming you (or me) find the required space that is...

Good point. It should also work for 2-player alternating, it'd be just the co-op and fight that don't support it. I'll spend a little more time on it before posting RC 5 (with the fix for the afore mentioned player 2 shield glitch), though I do need to get back to that other project as well as finish my presentation for next weekend.

A few very minor things I noticed at the menu (I suppose most have already been explained and have a reason):

- OPTION and SHIELD are very close together. To increase the gap, you could shorten the E and L like you already did in BONUS LIFE.

- a lower case K might look better for 5K, 10K, 20K

- 180° would IMO look better than just 180

- why is the menu entry label animated, but not the value? IMO both should be, especially since the current line is a bit hard to recognize already.

- why 4 control options when there is just 1 player or 2 players which share the control?

- the fonts in the menu and inside the game are very different. Especially the 2 and Y this is very noticeable. Maybe it would be better to align the menu font a bit to the in 7 segment in game font?

 

Some remarks for in game

- Probably that was explained already too, but why are only the large asteroids vector style? Space? (BTW: The player's ship is always solid too, but not in the menu, so maybe use a UFO or saucer there instead

- the player's ship explosion looks a bit odd, it seems too high

- instead of a color change, I would personally prefer a (flickering) circle around the ship to indicate the shield.

- if prefer to you keep the color change, its e.g. brightness could also represent the shield status

Lots of good menu suggestions, will take a look this weekend.

- only the menu entry label is animated because it was too difficult to see which color you were selecting. That came up from a comment by Nathan in this blog entry.

- wasn't ROM space to make the controller option select between 2 or 4 options based on the selected players value.

 

On the game options

- large vector asteroids but solid everything else means an old build of Stella. It was fixed in version 3.7.1.

- will take a look into the explosion, it might not be considering the Y adjust of the ship (used to save ROM space by not requiring the leading spaces to be stored in the images).

- I think Nathan and I had talked about a circle, but the ship spans 9 pixels, not 8 (there's a X offset for half the rotation) so the shields would "wobble" if the player rotated the ship.

- The monochrome games change the luma value to represent shields so that wouldn't work for them, and a lot of people prefer the mono versions.

Updated Stella so that I won't report non-issues again.

 

Could the selected item animation become a bit more obvious? Maybe a brighter variation of gray? Currently I don't even really notice the color change, just only that the bright center is flickering up and down.

 

The 1 player controller selection, is that a graphics size problem, or a code size problem? Probably both, right?

 

One could flicker the left and right most part of the shield circle, but I suppose that would look way too flickery. Maybe if the shield would be animated in a way that it never needs the full 9 pixel width. E.g. quickly rotating segments. Or dotted pixel...

 

Or the shield size would be just 8 pixel...? Nah!

Sure, will modify the luma values for the "selected grey".

 

Code size problem. Graphic size problem would be for showing 180°, there's a graphic image for "<space> 1" that's reused a number of times in the menu, including for displaying 180. Making it 180° means I'll need to add a new "18" graphic image and revise the exiting "80" graphic to be "0°".

Maybe we can find enough space even for those minor issues.

 

 

A major issue for me: When the game is over, it automatically switches to the menu pretty fast. IMO it would be better to stay in game until the player presses fire (though that may happen accidentally, hm...) . Or at least longer. Else you risk to miss your final score. Or maybe display it on the menu page?

 

 

Also the collision detection seems a bit too forgiving.

 

Minor ones:

- IMO there are too many different fonts on the menu:

1. SPACE ROCKS

2. The options

3. START

(4. the logo)

It would become better if 1. and 3. use the same font. Should be easy, no?

 

- The FRICTION C is different to the other Cs.

I thought the collision detection was spot-on. You can float your ship right next to an Asteroid and not be destroyed, but move one pixel and *boom*. If a rock is heading right at your nose and you shoot it, the debris' momentum can make it appear you got hit and not destroyed.

 

For shields - what about flickering between the solid and vector version of the ship? Not sure what it would look like, but it would be distinct. Then right before you ran out of time the flicker rate could slow as a warning.

Maybe its a matter of speed. Sometimes I seems like shots go right through the player's ship and that you can fly it through small asteroids.

 

I like the flickering idea.

I just tested again. It seems worse in vector mode. Saucer shots go through pretty often.

I can increase the "game over" delay. it's set to 120, which is 2 seconds. The counter uses bit 7 to denote that the game hasn't ended, so I'll have to modify the countdown routine to use something like if (FRAME & 1) END_OF_GAME_DELAY--.

 

Hmm, collision detection should be pixel perfect. Was there something specific that made it seem too forgiving?

 

1. Nathan's going to redo "Space Rocks" to match the winning label, what's there is something I threw together.

2. inconsistencies like the C within the options will be fixed

3. looks like the S and R in START should be redone to better match the options font.

4. not going to change the logo as it should match my other games. I should probably make the C in the options match the C in the logo though.

new comments while I was composing mine!

 

It shouldn't matter if solid or vector version of the game is selected as the solid image is always used for collision detection. I wonder if a solid and vector image got mismatched somehow. I should be able to make the game alternate solid/vector every other frame to easily see if something got out of whack.

 

alternating solid/vector is an interesting idea for shields.

I can increase the "game over" delay. it's set to 120, which is 2 seconds. The counter uses bit 7 to denote that the game hasn't ended, so I'll have to modify the countdown routine to use something like if (FRAME & 1) END_OF_GAME_DELAY--.

Sounds good. Also you can see the last score in demo mode.

 

Hmm, collision detection should be pixel perfect. Was there something specific that made it seem too forgiving?

I guess(!) it comes from movement between two frames. The human brain interpolates intermediate frames for moving objects. Else we would see jumping objects.

 

So when an object moves e.g. 4 pixels/frame and would touch the edge of another object in the middle intermediate frame, the collision detection would not trigger. But the human brain will notice it.

 

I think those are the cases I noticed. E.g. when a saucer shot moves at 90° over the small front of the player's ship.

 

Not sure how to fix that without excessive calculations (e.g. like virtual intermediate frames or vector movements math).

 

How does you collision detection work in detail? Bounding Boxes for coarse detection and then pixel perfect matching?

 

I'll skip further space optimizations for the Logo until the final one is decided.

I played a bunch of games last night looking for collision issues and didn't see any, though I did see a couple "near misses" that were caused by objects that moved past each other so that their pixels never touched.

 

One thing that could exaggerate the "near misses" is that there's not enough CPU time to run collision detection for everything. When the asteroids move, nothing is checked, it's only when the other objects (ships, saucer, mines, shots) move that collisions with asteroids are checked.

 

In looking at OverScan logic, I see this:

 AnimateSprites(); // do this first so asteroids are in current rotation for any collision tests
MoveShots();
ProcessJoystick();
ProcessSpecial();
MoveAsteroids();

 

I just changed it to this

 AnimateSprites(); // do this first so asteroids are in current rotation for any collision tests
MoveAsteroids();  // do this second so asteroids are in current position for any collision tests
MoveShots();
ProcessJoystick();
ProcessSpecial();

which will probably give better results.

 

 

The function that detects collisions is called Collision(). It does bounding boxes then pixel perfect matching. It also handles how the TIA wraps the players so that a large asteroid at X position 159 will still collide with a shot that's at X position 8.

Think I spotted something - were you playing with Shields? I believe the changes made for Shield Recharge has caused the ship to be impervious to saucer shots if shields is the selected option. Try playing with hyperspace, 180 or X (nothing) and let me know if that fixes the collision problem you're seeing.

Yes, I played with shields. With other options I noticed no collision misses so far.

Great! I should be able to fix that fairly easily then.

Regarding the shields: I think they last much too long, making the game too easy with that option. Compared to Asteroids, they seem to work about twice as long, so 50% of the current time might fit better.

 

IMO