SpiceWare's Blog

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.

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

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.

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.

The problem showed up again today so the time remaining checks are in place for the 2nd and 3rd fireballs.