SpiceWare's Blog - release candidate 6

[RSS Bot]

• Added a fix for the "Saucer hiding out in the wrap-zone". What it does is as soon as the Saucer moves into the wrap-zone it stops making random direction changes until after it exits the wrap-zone on the other side of the screen.
  
• Updated "label by" in the easter egg
  
• centered the small saucer graphic
  
• Fixed the sprite jump glitch
  

The sprite jump glitch was very fleeting, but I hadn't noticed it before adding the vertical screen-wrap of the large asteroids so I figured it must be related to those routines. I built a test version that would force the asteroid's Y value to a value that would make the asteroids always wrap. Once I did that the "jump" became noticeable, but due to the sprite flicker logic it's easiest to notice if you select the kids level so there's just 2 non-flickering asteroids being displayed:

 

 

the orange asteroid "jumped" for 1 frame. It appears twice in the screenshot due to phosphor effect, the "jump" position is above the ship.

 

 

Once I was able to recreate it, I added a diagnostic output that used the score to display asteroid's X values. It would usually show 00-9F (159), but it would occasionally would show FF (255, but also -1 if treating the value as signed). The player reposition routine is only valued for values from 0 to 16x (I don't recall the exact upper range). X values from 16x-255 end up at an invalid location somewhere on the left side of the screen.

 

The ScreenWrapSprite() routine is supposed to keep the sprites X value between 0-159 so I took a look at that routine:

if (gSpriteX[index] < 0)

gSpriteX[index] += 160 << FRACTION_BITS;

else if (gSpriteX[index] > 159 << FRACTION_BITS)

gSpriteX[index] -= 160 << FRACTION_BITS;

 

at first glance it looks OK as we want to limit X to values from 0 to 159. However, we're dealing with fractional values so if the X position is 159.5 the routine ends up changing it to -0.5. The fractional part of the number is truncated when it comes time to position the sprite, so -0.5 becomes -1 (or FF). To fix it I changed the > 159 test to use >= 160 instead.

if (gSpriteX[index] < 0)

gSpriteX[index] += 160 << FRACTION_BITS;

else if (gSpriteX[index] >= 160 << FRACTION_BITS)

gSpriteX[index] -= 160 << FRACTION_BITS;

 

That fix should have helped as the score stopped showing X positions of FF, but the jumps were still occurring. So I next reviewed the new logic for wrapping the asteroid image around the screen. What I found was this:

 

PLAYER_X[1-stream] = gSpriteX[index] >> FRACTION_BITS;

...

// fat objects get displayed 1 pixel to the right, so compensate

if (size1) PLAYER_X[1-stream]--;

 

That would turn a 0 into FF for the large asteroids. I changed that routine to be as follows:

x = gSpriteX[index] >> FRACTION_BITS;

...

// fat objects get displayed 1 pixel to the right, so compensate

if (size1) x--;

if (x < 0) x += 160;

PLAYER_X[1-stream] = x;

 

And that took care of the remaining jumps.

 

 

ROMs

 

 

 

Test ROMs

 

 

 

Source

 

http://www.atariage.com/forums/blog/148/entry-9744-release-candidate-6/