XSpeed=XSpeed+cos(direction)*acceleration
YSpeed=YSpeed+sin(direction)*acceleration
If Bounced=False
ballX=ballX+XSpeed
ballY=ballY+YSpeed
If Bounced=True
ballX=ballX-XSpeed
ballY=ballY-YSpeed
2D Bounce Engine
Author
Basically I'm trying to create a realistic 2D Bounce Engine, and trying to understand as best I can. So I've been playing around with a bouncing ball in a few programs and wonderfully got the gravity, velocity, bounce, and everything working greatly with it. My next project (which I assigned myself last night) was to make a ball go in a random direction and then bounce off of the edges of the screen realistically. After pulling my hair for 4 hours I failed (although I'm still going to try again here)
What I managed to do with the balls is just reverse their direction by doing something like:
I'm not entirely sure if your simulation has a point of gravity, but if it has, then have a look at this this article. It discusses gravity for a platform kind of game. But if you replace Joe (from the article) with your ball, add a bit of horizontal movement to it, and include a wall check where you reverse the direction of your ball, then you pretty much have what you want.
Author
Well, I was using cos and sin to create my vector and I just discovered that it is much better just to make the vector off of simple x and y.
I would like to thank Anthony Flack for the answer (from indie developer forums)
his answer is as follows:
nstead of moving your ball based on cos and sin of an angle, you should deal with it directly as a vector - movement of x, and movement of y. Let's call them mx# and my#. Kind of like your xspeed and yspeed, but don't recalculate them each frame; leave them in a persistent state.
So every frame, you would just go
x:+mx#
y:+my#
to add gravity, it's easy:
my:-.05 (or some other number)
Here's what happens when the ball bounces off the ground:
my=-my
Or, if you want it to bounce a bit less each time
my=-my*.95
And similarly for bouncing off walls:
mx=-mx
--
I would like to thank Anthony Flack for the answer (from indie developer forums)
his answer is as follows:
nstead of moving your ball based on cos and sin of an angle, you should deal with it directly as a vector - movement of x, and movement of y. Let's call them mx# and my#. Kind of like your xspeed and yspeed, but don't recalculate them each frame; leave them in a persistent state.
So every frame, you would just go
x:+mx#
y:+my#
to add gravity, it's easy:
my:-.05 (or some other number)
Here's what happens when the ball bounces off the ground:
my=-my
Or, if you want it to bounce a bit less each time
my=-my*.95
And similarly for bouncing off walls:
mx=-mx
--
Quote:Original post by MattMcFarland
Well, I was using cos and sin to create my vector and I just discovered that it is much better just to make the vector off of simple x and y.
I would like to thank Anthony Flack for the answer (from indie developer forums)
his answer is as follows:
nstead of moving your ball based on cos and sin of an angle, you should deal with it directly as a vector - movement of x, and movement of y. Let's call them mx# and my#. Kind of like your xspeed and yspeed, but don't recalculate them each frame; leave them in a persistent state.
So every frame, you would just go
x:+mx#
y:+my#
--
Well... i would still say that you should try with your Cos and Sin since u will proberbly come to muchs use of it...
And your mx and my vector is just calculated from sin and cos...
then u will be able to make turns as well and it is not that hard...
what u basicly want is a Direction (between 0 and 360 degrees) and a Speed...
then:
mx = Speed * Cos(Direction)
my = Speed * Sin(Direction)
B_U_T!!!
Depending on what language us use this might not give the desired result...
What u have to remember is, what do u have to feed your Cos and Sin methods with? Degrees or Radians?
For .NET as an example u have to convert your degrees to Radians for it to work...
Done very simple:
Degrees to radians:
((PI * deg) / 180)
Radians to degrees:
((180 / PI) * deg)
Just as a side note: if you don't move the object out of the collision and you add friction to the bounce the object may get stuck in the collision. Say if it takes 3% of the velocity to collide with the wall and you multiply by 0.95 and subtract then you are still 2% of your velocity in the wall and on the next frame your ball is going to bounce towards the wall and so on and so forth.
I'm working on a 2d physics engine now, I have the point bouncing off an edge (you can treat the edge as a ray), Here's the code..
BTW: The Angle class is using radians, so I don't have to convert them back
and forth. It automaticly wraps around, I can post the code if you want.
This is C# by the way
BTW: The Angle class is using radians, so I don't have to convert them back
and forth. It automaticly wraps around, I can post the code if you want.
//a is the point that will bounce offAngle pointAngle = a.MoveAngle;//The ray that the point will bounce off ofAngle lineAngle = new Angle((float)Angle.GetAngle(p1.Y - p2.Y, p1.X - p2.X));//A line perpendicular (normal) to the lineAngleAngle normalAngle = new Angle(lineAngle.A);//The distance between the point and the normalfloat gap = normalAngle.A - pointAngle.A;//If the normal is facing the wrong directionif (gap > FMath.PI){ //(remember, all of this is using an Angle class,it wraps around) //Flips the normal normalAngle.A -= FMath.PI; //recaclculate the gap so that it is correct gap = normalAngle.A - pointAngle.A;}//The gap added to the normal is the bouncing off pointa.MoveAngle.A = normalAngle.A + gap;This is C# by the way
Author
Wow, thanks alot guys. I appreciate your help. I couldn't see how the concept worked but now I do so I can implement this now.
One question.
If I have two objects, one is static, and one is moving.
Moving object hits static object. To find out where moving object should bounce I need not worry about static object at all right? Just the coordinates of the static object so I can identify that the moving object hit the static object.
so the moving object has now made a collision. So we find the angle of the moving object and then adjust it's direction accordingly.
Now, my mathematical handicap is taunting me right now. I'm thinking things like "but if it hits the right side of an object its angle has to go this way and if it hits the left side object the angle has to go this way. how does it know where the angle should go?"
But my logical mind says, "It doesn't matter. It's velocity and angle are all that is needed to know where it'll go next."
But then I end it with ".....or does it?"
...Your thoughts? :-)
One question.
If I have two objects, one is static, and one is moving.
Moving object hits static object. To find out where moving object should bounce I need not worry about static object at all right? Just the coordinates of the static object so I can identify that the moving object hit the static object.
so the moving object has now made a collision. So we find the angle of the moving object and then adjust it's direction accordingly.
Now, my mathematical handicap is taunting me right now. I'm thinking things like "but if it hits the right side of an object its angle has to go this way and if it hits the left side object the angle has to go this way. how does it know where the angle should go?"
But my logical mind says, "It doesn't matter. It's velocity and angle are all that is needed to know where it'll go next."
But then I end it with ".....or does it?"
...Your thoughts? :-)
If a moving object hits a static object you need to consider the surface normal(the vector at a right angle to the surface pointing outwards) of the static object. This is how your program determines if "it hits the right side or the left side". Basically, to get your exit angle you reflect your entrance angle over the normal angle (that's exactly what FreeDebreuil's program is doing).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
