Jump to content
  • entries
    657
  • comments
    2,699
  • views
    900,426

Lack of time, part 2


SpiceWare

634 views

Turns out the lack of time was also occuring during the overscan when processing fireball collisions.

 

The fireballs are 2 pixels wide and 4 pixels tall; but, because I'm using a 2 line kernel, I can consider it 2 pixels tall.

 

in the original routines, the process for fireball collisions on the grey castle was:

if BrickHit(x,y) then
RemoveBrick(x,y)
elseif BrickHit(x,y+1) then
RemoveBrick(x,y+1)
elseif Brick(x+1,y) then
RemoveBrick(x+1,y)
else BrickHit(x+1,y+1) then
RemoveBrick(x+1,y+1)
endif
 

 

where x,y is the top left of the fireball and x+1,y+1 is the bottom right of the fireball.

 

This weekend I was playing Super Breakout for the High Score Club and noticed that the ball would occasionally pass thru a brick. That lead me to realize they only tested the left side of the ball when a collision occured. I decided to do the same. After making the change, I ran MM in Stella for a few hours today with the following break in the debugger to confirm the screen problem had cleared up:

breakif { _scan == #263 }

 

Since I'm only testing 1 corner, I picked the corner closest to the king for each castle: grey uses x,y, blue uses x+1,y, purple uses x,y+1 and green uses x+1,y+1.

 

It works OK, but I'm not totally thrilled with the change. If processing time allows, I plan to revise the routines to check the 2 opposite corners of a fireball, grey would either check(x+1,y) and (x,y+1), or possible (x,y) and (x+1,y+1) depending on how tests go.

Medieval_Mayhem.zip mm20060917NTSC.bin mm20060917PAL.bin

5 Comments


Recommended Comments

I would suggest that it might be good to have the code "philosophy" be to use quick tests to determine when you're likely to have to do some "real" work, and then arrange so that you only do the "real" work for one ball on any given frame.

 

If you have time and memory to read and store collision registers mid-frame, they should help your code very quickly determine whether any sort of bounce seems likely. If a ball hasn't collided with anything, there's no need to check the brickmap. If a ball has collided, you may need to check up to 4 bricks depending on its position, so that could take longer. I don't think there'd be any harm with only checking one collided ball per frame, though, if you use flags to mark the other balls as being "deferred". If a collided ball is deferred, don't move it on the next frame, but keep track of how many frames (1 or 2) have lapsed since its collision and then move it more on the following frame.

 

BTW, IMHO, a ball should generally remove a maximum of one brick per collision. If it collides with two side-by-side bricks, take out the one "upstream" of the ball's direction of movement. If two vertically-adjacent bricks, do likewise. If two diagonally-placed bricks, take both and bounce 180 degrees. If three bricks, take out the two diagonally-opposite ones and bounce 180 degrees.

Link to comment
If a ball hasn't collided with anything, there's no need to check the brickmap.
The collision registers are checked first and the psuedo code shown only runs if the fireball in question hit the playfield.

 

I don't think there'd be any harm with only checking one collided ball per frame, though, if you use flags to mark the other balls as being "deferred".
I currently have the routines set up to skip the collision/movement processing of the last fireball if there's insufficient time to process the collision.

 

Frame 1 - fireball 1 = M0, fireball 2 = M1, fireball 3 = BL

Frame 2 - fireball 1 = BL, fireball 2 = M0, fireball 3 = M1

Frame 3 - fireball 1 = M1, fireball 2 = BL, fireball 3 = M0

repeat

 

For each frame, the last fireball processed(always M0) is tested for time remaining.

 

I'm going to revise the routines to do a 2-corner test first and see how that works out. If it doesn't, then I plan to revise the time-remaining test to also occur for M1. Because of the fireball rotation, I don't need to flag anything as deferred as by skipping the movement of the fireball the collision will occur again on the next frame.

 

BTW, IMHO, a ball should generally remove a maximum of one brick per collision.

That's how it works - the tests are done "elseif" so only 1 brick is removed per frame.

 

As always - I appreciate the input :party:

Link to comment

Didn't like the results of the 2 corner test I did today so I'll be adding back the 4 corner test and adding a time-remaining check on the 2nd fireball like there is with the 3rd fireball.

Link to comment

I added back testing for all 4 corners and set the time-remaining checks really low so I'd get a screen roll. Been running MM for 2 hours and not one roll has happened. Weird. :party:

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...