Pool Table Math - Can anyone help?

[MausBoy]

I've got the ball rolling and bouncing off of walls, but I don't know how to make up/down left/right independent so that they work correctly. If I use seperate variables to detect movement/collision, then for instance:

If the ball is moving up and right and hits a wall above it, it will bounce back and move down and left. I would want it to keep going right and just bounce down. If I use the same variable, then it works fine for up/down, but then left/right don't work. This is how it is configured in the attached bin(one variable), and the variables are j and k for using two (I switched out the k's, but they are the mbally variable, j is the mballx one).

 

I hope that makes sense. I've included the bin so you can see what I mean. Anyone have any ideas on how to set this up so that it works just like a ball on a pool table? I know my code is an ugly mess, but it should be readable.

 

Thanks in advance if anyone has any suggestions.

mausball1b.bas

mausball1b.bin

Edited December 1, 2006 by MausBoy

[kisrael]

Wow, that's going to be tough.

 

One rough idea that uses a lot of flicker: instead of one sprite, make it four sprites, one for each quarter of your ball: NW, NE, SW,SE.

Each frame, rotate through to the next position.

If there's a player / playfield collision, set the variable for the current direction, other wise unset. Then, if any 2 variables are set (like NW and SW), you know it hit on the West side, and so the direction should be East...

 

This could create more problems, and will flicker like crazy, but might be worth a shot...

[kisrael]

I should say, other approaches would have to know more about the shape of the playfield, and where the ball was relative to it.

[MausBoy]

I could achieve that effect by strobbing a missile sprite in the four corners of the ball, without needing to flicker the ball, I just find that type of programming extremely frustrating and resource consuming. I was hoping there was a simple way using flags that I'm just too dense to figure out. As you can see if you check my code, I've already got a pretty big mess going just to get it to do what it does so far.

[kisrael]

I could achieve that effect by strobbing a missile sprite in the four corners of the ball, without needing to flicker the ball, I just find that type of programming extremely frustrating and resource consuming. I was hoping there was a simple way using flags that I'm just too dense to figure out. As you can see if you check my code, I've already got a pretty big mess going just to get it to do what it does so far.

I hear you pal.

 

I admit my knowledge of Atari internals is rusty, but I'm pretty sure there's no register magic that would let you know where on the sprite it was hit, or where the sprite is relative to the nearest chunk of Playfield. If you wanted to be sure you could check some of the other forums, but...

 

Programming Hygiene is tough, and historically BASIC isn't the easiest language to keep things structured in...that's why you need good old discipline

[Bruce Tomlin]

You can know the vertical position by checking the collision registers on every scanline, but that would be a bit much to ask from BB.

[SeaGtGruff]

Thanks in advance if anyone has any suggestions.

I think you should be able to peek ahead at the playfield using pfread, based on the direction the ball is moving, but I don't have time right now to check your code and post a suggested routine-- maybe late tonight or sometime tomorrow.

 

Michael

[+batari]

Thanks in advance if anyone has any suggestions.

I think you should be able to peek ahead at the playfield using pfread, based on the direction the ball is moving, but I don't have time right now to check your code and post a suggested routine-- maybe late tonight or sometime tomorrow.

 

Michael

Yes, pfread is the best way. It's not too hard to convert player XY to playfield XY. I do it all the time.

 

IMO, in general, hacking in collision checks on every scanline in the kernel isn't a good idea, as kernel time is too valuable to waste on a problem that is solvable outside the kernel.

[kisrael]

I think you should be able to peek ahead at the playfield using pfread, based on the direction the ball is moving, but I don't have time right now to check your code and post a suggested routine-- maybe late tonight or sometime tomorrow.

Yes, pfread is the best way. It's not too hard to convert player XY to playfield XY. I do it all the time.

Really? Even when the player is moving in smaller chunks than the playfield squares?

[+batari]

I think you should be able to peek ahead at the playfield using pfread, based on the direction the ball is moving, but I don't have time right now to check your code and post a suggested routine-- maybe late tonight or sometime tomorrow.

Yes, pfread is the best way. It's not too hard to convert player XY to playfield XY. I do it all the time.

Really? Even when the player is moving in smaller chunks than the playfield squares?

The size of the chunks doesn't matter if we use a bounding box method. The player can only collide with the playfield in units of 4 or 8 this way.

 

The conversion involves adjusting the player XY by adding or subtracting a fixed amount depending on the size and shape of the player, and dividing the adjusted X by 4 and the adjusted Y by 8.

 

No hardware collision checks are even necessary. But you can make it more accurate by only checking the bounding box if a hardware collision occurs, and as long as your player isn't a really funky shape, it will work just fine.