Jump to content





bug fixes

Posted by SpiceWare, in Space Rocks 06 August 2012 · 496 views

  • fixed explosion bug in FIGHT mode
  • fixed bug were player 1's HMOVE shift data (for large asteroids) was getting wiped out, causing the large asteroids to occasionally be drawn "chunky style"
  • sped up the explosion sequences
ROMs
Attached File  spacerocks20120806b_NTSC.bin (32KB)
downloads: 80
Attached File  spacerocks20120806b_PAL.bin (32KB)
downloads: 62

Source
Attached File  spacerocks20120806.zip (812.3KB)
downloads: 62


respawn window:
Attached Image




The explosions look a lot better now. Thanks, Nathan!!
  • Report
It was a good suggestion. It always helps to have extra sets of eyes looking at those sorts of things.
  • Report
Why is it that when you die and you're still in the center that when you return to the screen you're in a different location?
  • Report
It'll only return you to a location on screen where there are no rocks.
  • Report
In Asteroids you always return in the middle. In Space Rocks you return to 1 of 5 locations due to a couple reasons:
  • 2 player fight mode - if you always returned to the middle, the other player could prevent you from respawning by staying in the middle.
  • In earlier builds (pre-2 player) when it only respawned in the middle, I had a few occurrences of an exceptionally long respawn time. Having 5 different respawn locations made that problem go away.
  • Report
After playing for a little while (in one player mode) I feel that it is taking too long to re-spawn. Lots of the time I felt the ship could re-spawn but didn't.


I was also wondering if you could make it default to the middle when when the middle is available? Lots of times the middle was available, but the ship would re-spawn in one of the other four locations. I completely understand the need for the other locations if two players are on the screen, but in one player mode it would be good to default to the middle (when available).

If you are using a windowed area approach to determine when it is safe, then perhaps narrowing the window would do the trick?
  • Report
For performance reasons I wrote the respawn routine to only check 1 of the 5 locations per frame, you're warped in as soon as possible. The locations are checked round-robin, so if the middle is checked this frame, the next frame will check one of the "corner" locations. The next 3 frames check the other 3 corners. It's back to the middle for the frame after those. Part of the reason for the new warp-in effect and flashing temporary immunity is to give you time to spot were your ship respawned at.

Yes, I use a windowed area to test. The window's supposed to shrink over time, but in looking over the code I see that the variable RESPAWN_ZONE_ADJUST[player] isn't getting changed. I suspect I accidentally deleted the adjustment code when I rewrote the routine for multiple respawn locations. I'll take a look at that this weekend.
  • Report
I added some code that uses the missiles to draw the "respawn window" whenever the program's testing to see if it can respawn the ship. See the new screenshot added to the blog entry to see what it looks like.

One thing I have noticed early on was the respawn window went away if the saucer showed up. The window came back after the saucer went offscreen. This means it stopped trying to respawn for the duration of the saucer's appearance. That could explain why you saw occasions where the ship could have respawned but didn't.

This would have started July 1st as that's when I changed the respawn logic to match the arcade were if the saucer killed you the respawn was delayed until the saucer went offscreen.

I some ideas on how to fix it, but won't get to them until tomorrow.
  • Report

Search My Blog

Recent Entries

Recent Comments

Latest Visitors

0 user(s) viewing

0 members, 0 guests, 0 anonymous users