 |  |  |  |  |  |  |  |
Breakout Ball bouncing physics
 |
•
•
Join Date: Jul 2006
Posts: 1,091
Reputation: 
Solved Threads: 63
Where and what are the issues? Do they occur at the 'corners and sides' of the paddle, or at the flat, upwards pointing, part? What exactly doesn't seem right when you test?
Plato forgot the nullahedron..
•
•
Join Date: Jan 2008
Posts: 401
Reputation:
Solved Threads: 40
Posting Pro in Training
Wthe ball hits the side of the paddle, it ussualy just goes through the paddle and starts spazing, and then comes out when I move the paddle away. Bouncing on the top side works well, but I have some issues with bottom bouncing as well (when the ball moves below the paddle it starts moving straight until it moves out from under the paddle).
I'm a student. If my statements seem too absolute, feel free to coat them with "In my opinion..." or "I believe...".
•
•
Join Date: Jul 2006
Posts: 1,091
Reputation:
Solved Threads: 63
Hi, sorry I didn't reply sooner, been abit busy.
With movement and collision, you have a couple of pitfalls. One is that the speed/velocity of a moving object can exceed the width of objects being tested against, a symptom of this is moving objects 'tunneling through' other objects. This occurs when you use 'static collision testing', which is testing the current position of objects in each iteration as opposed to testing the positions and trajectories of objects. With static tests, two collision tests ( in two frames/iterations ) can report a non-collision even though the trajectory of an object may have passed right through another object.
You can often get away with static tests by increasing the number of iterations and decreasing the maximum velocities involved, this means you can keep the same 'visual speed', but objects are actually moving much less between frames and being collision-tested much more frequently.
Another specific problem with the bounce method you're using is that the ball can be collision-tested as being below paddle.top( ), your code will flip the velocity of the ball; in the next frame, the ball might not escape the collision between paddle.top( ), meaning the ball trajectory gets flipped again, and again, and so on. The ball would indeed 'spaz about' in that case, the ball never actually escapes the top of the paddle.
Two viable fixes:
This assumes that y=0 is the top of the screen, effect is slightly displacing ( separating ) the ball position from the collision, so that the ball can start moving away without getting stuck in this test. Another solution:
( again assuming that negative velocity in Y goes upwards, if not the case, remove the *-1 ). Need to #include <cmath> to get fabs, and fabs just takes the absolute of a floating point number ( i.e. without the sign ). This way, you can always push the ball 'upwards'.
I said two viable solutions.. there's actually three, the last is to use vector math to calculate the reflection against the surface based on the normal of the surface.. equation for which is something like:
( not tested )
With movement and collision, you have a couple of pitfalls. One is that the speed/velocity of a moving object can exceed the width of objects being tested against, a symptom of this is moving objects 'tunneling through' other objects. This occurs when you use 'static collision testing', which is testing the current position of objects in each iteration as opposed to testing the positions and trajectories of objects. With static tests, two collision tests ( in two frames/iterations ) can report a non-collision even though the trajectory of an object may have passed right through another object.
You can often get away with static tests by increasing the number of iterations and decreasing the maximum velocities involved, this means you can keep the same 'visual speed', but objects are actually moving much less between frames and being collision-tested much more frequently.
Another specific problem with the bounce method you're using is that the ball can be collision-tested as being below paddle.top( ), your code will flip the velocity of the ball; in the next frame, the ball might not escape the collision between paddle.top( ), meaning the ball trajectory gets flipped again, and again, and so on. The ball would indeed 'spaz about' in that case, the ball never actually escapes the top of the paddle.
Two viable fixes:
if(m_position.y+m_height >= paddle->GetY() && m_position.y <= paddle->GetY() + paddle->GetHeight() && m_position.x+m_width/2 > paddle->GetX() && m_position.x+m_width/2 < paddle->GetX() + paddle->GetWidth())
{
m_velocity.x += paddle->GetMoveX()*(0.25);
m_velocity.y *= (-1);
m_position.y -= [a small number];
}if(m_position.y+m_height >= paddle->GetY() && m_position.y <= paddle->GetY() + paddle->GetHeight() && m_position.x+m_width/2 > paddle->GetX() && m_position.x+m_width/2 < paddle->GetX() + paddle->GetWidth())
{
m_velocity.x += paddle->GetMoveX()*(0.25);
m_velocity.y = fabs( m_velocity.y ) * -1;
}I said two viable solutions.. there's actually three, the last is to use vector math to calculate the reflection against the surface based on the normal of the surface.. equation for which is something like:
velocity2 = ( 2 * surface_normal * surface_normal.dot( velocity1 ) ) - velocity1;
Plato forgot the nullahedron..
•
•
Join Date: Jul 2006
Posts: 1,091
Reputation:
Solved Threads: 63
Based on a quick test in something I've got running ATM, that last bit of code I posted:
Should probably be:
!
velocity2 = ( 2 * surface_normal * surface_normal.dot( velocity1 ) ) - velocity1;
velocity2 = velocity1 - ( 2 * surface_normal * surface_normal.dot( velocity1 ) );
Plato forgot the nullahedron..
|
Other Threads in the Game Development Forum
- Previous Thread: looking for software and computer advise for gaming
- Next Thread: Is this software better for game developement.?
| Thread Tools | Search this Thread |
You need to join our community in order to build your list of favorite forums. You can visit the forum index for a listing of all forums.
Related Forum Features
Latest Game Development Posts
- Today's Posts
- Unanswered Threads
3d advertising ai algorithm ban c++ cambridge camera censorship china competition console development engine fov fpx game gamer games gaming gauntanamo government idaho in-gameadvertisement intellectualproperty laracroft live manhunt math mathematics matrix mercenaries microsoft mmorpg modded msn naked news nintendo obama palin physics pirate playstation politics projection ps3 rpg search software sony stephenhawking stocks studio technology terrorism tombraider uk videogame web wii world-of-warcraft xbox xbox-live xbox360