# Physics movement prediction is way off [closed]

I'm making a simple, non-networked game. There are two players and a ball. In implementing the AI for the second player, I've run into a huge problem predicting where the ball will hit the ground. Either I've made a mistake in the physics engine or in implementing the prediction itself. I wrote the physics engine, and while it works visually as I expect it to, I won't rule it out as a suspect. First I'd like to make sure I haven't made a mistake in the prediction code. Here's what I have found so far:

I print the predicted time to impact and the accumulated time in each frame. The time predicted for impact is way off.

``````tti: 0.678233
total time: 0
.
.
tti: 0.0108339
total time: 0.94969
[ball] ground collision
``````

The code for predicting is in two functions.

``````double nextBallCollisionWithGround(Ball *ball, double groundHeight) {
std::cout << " tti: " << timeToImpact << endl;
double groundPos = -3.;
if (timeToImpact > 0) {
groundPos = ball->velocity().x * timeToImpact + ball->position().x;
}
return groundPos;
}

double quadraticSolver(double a, double b, double c) {
double ans = -1.;
double det = (b*b) - (4.*a*c);
double t1, t2;
if (det > 0.) {
t1 = (-b + sqrt(det)) / (2. * a);
t2 = (-b - sqrt(det)) / (2. * a);
if (t1 > 0.)
ans = t1;
if (t2 > 0.)
ans = t2;
}
return ans;
}
``````

If there's no problem in these functions, I can include the relevant parts of the physics engine to see if the problem is there.

-

## closed as too localized by Sean Middleditch, Byte56♦, Josh Petrie♦, Trevor Powell, sam hocevarMar 1 '13 at 15:29

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Voting to close for "debug my code for me." This would be better asked in our chat or in a discussion forum which is designed for personal assistance. We're aiming for more universal and concrete Q&A, here. :) – Trevor Powell Feb 13 '13 at 0:22

I don't know what `kGravity` is, but it should be half the gravitational acceleration.

Because the formula is:

``````h(t) = t * velo_y + 0.5 * -gravity * t^2
``````

Where, `h(t)` is the height in function of time, `t` is the time and `velo_y` is the initial y velocity. And `gravity` is for example `9.81 m/s^2`.

So, as you can see, the `a` of the quadratic equation is `0.5 * -gravity`.

Some remarks:

• Little imperfection to your quadratic solve method: the determinant can be zero as well. You will have two identical roots.

• In order to get the correct root for this equation, you should make sure you are taking the smallest positive root for your collision prediction.

-
That was exactly it! Thanks for catching it. I made some simplifying assumptions for the quadratic solver, but should probably just modify it as you recommend so it doesn't bite me later. – brodney Feb 10 '13 at 16:53
My second remark is quite important on the solver. As soon as your values (heights, speeds, distances) get higher, this will be your next problem. – Martijn Courteaux Feb 10 '13 at 16:57
Actually, the OP's solver does always return the smallest positive real root (if any), since `sqrt(det) >= 0` and thus `t1 >= t2`. Anyway, as long as the ball stays above the ground (and gravity pulls it downwards), the OP's quadratic equation will always have exactly one positive root. The only way there could be two positive real roots would be if the ball was below the ground and moving upwards. (Anyway, +1 for spotting the missing factor of 1/2.) – Ilmari Karonen Feb 10 '13 at 23:24
Yes, t1>=t2, but check out his assignment order. – Martijn Courteaux Feb 11 '13 at 15:08