Jump to content
  • entries
    657
  • comments
    2,698
  • views
    899,221

revamped respawn


SpiceWare

1,022 views

  • revised the respawn logic.
    • ship can once again respawn while saucer is on screen.
    • respawn zone shrinks every 60 frames (once per second).
    • in 1 and 2-player-alternating games, respawn now always occurs in the middle of the screen.

    [*]fixed warp-in offset problem

    [*]ship explosion back to displaying each image in the animation sequence for 4 frames. Other explosions still display for 3 frames per image.

 

For fun I uploaded "debugging builds" so y'all could like to see what I added to test the respawn routines. I've been setting the game to Level: Kids so the asteroids move slower. The debugging builds have the following features:

  • displays the respawn zone in 1 player games.
  • start each wave with 12 asteroids.

the player's 4 shots mark the boundaries of the respawn zone (bottom-right shot is hidden by the blue asteroid)

blogentry-3056-0-30999600-1344719267_thumb.png

 

shrinking respawn zone

blogentry-3056-0-06661200-1344719276_thumb.png

 

For those of you reviewing the source, defines.h contains the following define that can be uncommented to enable the code that displays the respawn zone:

//#define SHOW_RESPAWN_ZONE

 

ROMs

spacerocks20120811_NTSC.bin

spacerocks20120811_PAL.bin

spacerocks20120811_NTSC_debugging_build.bin

spacerocks20120811_PAL_debugging_build.bin

 

Source

spacerocks20120811.zip

5 Comments


Recommended Comments

F.Y.I. The shields just flicker in this build, almost like... Well not like the throb at the start of a game. This was a quick observation in blue and b/w mode, vector.

Again (& again) great job!

Link to comment

Oops - had made a chance to the "CycleColor" routine so the ship explosion would look better in the monochrome game variations. I forgot the same routine was used for the shield coloration. I restored the code to the prior version so it'll be fixed in the next release.

Link to comment

Thanks for the updates. On the normal rom, I feel the size of the window is too big in the beginning rounds when there are not a lot of space rocks. Maybe the initial size should be correlated to the number of space rocks on screen? In the debugging test rom when there were lots of space rocks on the screen the big window worked well.

 

On the normal rom with just a few space rocks though it seemed like that there was always just one space rock slipping through the corner that prevented re-spawn.

 

 

I'm betting you don't have the cycles or rom left to do some elaborate calculations to see if the asteroids on a trajectory to the re-spawn location, hence use of the windowed area approach.

 

 

Edit:

Forgot to say I haven't looked at the code at all. Not much time for a few days yet.

Link to comment

It's easier to have one size window than having to resize it based on the number of asteroids on screen. I can make it so the window shrinks faster, it's defined by a constant in defines.h:

 

// shrink respawn zone every x frames

#define RESPAWN_ZONE_SHRINK_TIME 60

 

 

Just finished adding "select your own color". Instead of the 3 hardcoded presets, you can now select any of the 16 base colors. Surprisingly enough, doing this saved quite a bit of ROM over having 3 hardcoded monochrome presets. Now I have to add some conditional compile logic so the PAL version selects from the 13 base colors, otherwise PAL users will have 4 choices for white :)

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...