"I'm not sure how a high logic rate (IM)proves accuracy."
It's quite simple really.
Imagine you have a ball sitting on the ground. Your ball is being pulled down by gravity. We'll pretend the game is running at 1fps, so each frame you add -9.8 to the ball's speed on the Y axis.
Now when the ball collides with the ground, if we are talking a perfectly elastic collision where all energy is returned (not realistic) the ball's velocity is reversed. So the ball is now moving at +9.8 meters per second. Now when the gravity from the next frame is added, another -9.8, the two cancel eachother out exactly, and the ball's velocity returns to 0.
You might be able to shuffle the order you do things and move the ball back so it is outside of the ground to get this to sit perfectly stable at 0, but either way, you've got a pretty stable simulation there.
But what happens when the time between frames varies? Now, the next frame may take less time to render. And that means that you're adding slightly less than -9.8 to the ball's velocity. And that means that you don't exactly cancel out it's upward movement. So now the ball moves away from the ground a little more than it was before.
Then it gets messy.
Now that the ball is a little farther away from the ground, it might happen that the next frame, which also takes less time to render, doesn't add enough gravity to the ball to move it far enough to collide with the ground. Now you're gonna have TWO frames of gravity acceleration before the ball hits the ground! And that means that the ball will rebound with that much more force.
This is what we call a physics explosion. Where you have a an oscillation in your velocity... (Imagine a straight line on a graph, which suddenlly turns into a sawtooth wave) which gets bigger and bigger... (the sawtooth grows in amplitude) so much so that evenetually the ball gets stuck in the ground for a moment, shakes violently, and then explodes out of it, shooting off into the wild blue yonder, never to be seen again.
Now when you have perfectly elastic collisions, the physics aren't TOO hard to manage. But when you start having that sphere lose some of its velocity on each bounce? Then if you don't have things set up just right and move the ball back out of the ground when a collision is detected to keep them from interpenetrating, then you have problems like, the ball hits the ground and gets stuck because it tries to exit on the next frame but doesn't move far enough. Or worse, and more likely, it sinks into the ground and dissapears.
Another issue with Delta_Time is that if you have the same game running on two systems, even if you fire a projectile from the same location, at the same speed, in the same direction, you can get a situation where one PC thinks the projectile hit a corner and bounced off, and the other thinks the projectile missed the corner completely and it keeps moving. Of course this is mainly an issue in online multiplayer games.
If we had perfect collision detection systems in our games that could tell the exact time and point of a collision, and did everyhting jsut right, then this might not be as much an issue, but for the most part we don't. So it is. And the easiest fix if this becomes an issue (it ususally isn't unless you're simulating complicated physics) is to up the number of times you run your physics each frame, making the error smaller, or to try to make the time steps identical to reduce the error to 0, or as close to it as possible.
It's quite simple really.
Imagine you have a ball sitting on the ground. Your ball is being pulled down by gravity. We'll pretend the game is running at 1fps, so each frame you add -9.8 to the ball's speed on the Y axis.
Now when the ball collides with the ground, if we are talking a perfectly elastic collision where all energy is returned (not realistic) the ball's velocity is reversed. So the ball is now moving at +9.8 meters per second. Now when the gravity from the next frame is added, another -9.8, the two cancel eachother out exactly, and the ball's velocity returns to 0.
You might be able to shuffle the order you do things and move the ball back so it is outside of the ground to get this to sit perfectly stable at 0, but either way, you've got a pretty stable simulation there.
But what happens when the time between frames varies? Now, the next frame may take less time to render. And that means that you're adding slightly less than -9.8 to the ball's velocity. And that means that you don't exactly cancel out it's upward movement. So now the ball moves away from the ground a little more than it was before.
Then it gets messy.
Now that the ball is a little farther away from the ground, it might happen that the next frame, which also takes less time to render, doesn't add enough gravity to the ball to move it far enough to collide with the ground. Now you're gonna have TWO frames of gravity acceleration before the ball hits the ground! And that means that the ball will rebound with that much more force.
This is what we call a physics explosion. Where you have a an oscillation in your velocity... (Imagine a straight line on a graph, which suddenlly turns into a sawtooth wave) which gets bigger and bigger... (the sawtooth grows in amplitude) so much so that evenetually the ball gets stuck in the ground for a moment, shakes violently, and then explodes out of it, shooting off into the wild blue yonder, never to be seen again.
Now when you have perfectly elastic collisions, the physics aren't TOO hard to manage. But when you start having that sphere lose some of its velocity on each bounce? Then if you don't have things set up just right and move the ball back out of the ground when a collision is detected to keep them from interpenetrating, then you have problems like, the ball hits the ground and gets stuck because it tries to exit on the next frame but doesn't move far enough. Or worse, and more likely, it sinks into the ground and dissapears.
Another issue with Delta_Time is that if you have the same game running on two systems, even if you fire a projectile from the same location, at the same speed, in the same direction, you can get a situation where one PC thinks the projectile hit a corner and bounced off, and the other thinks the projectile missed the corner completely and it keeps moving. Of course this is mainly an issue in online multiplayer games.
If we had perfect collision detection systems in our games that could tell the exact time and point of a collision, and did everyhting jsut right, then this might not be as much an issue, but for the most part we don't. So it is. And the easiest fix if this becomes an issue (it ususally isn't unless you're simulating complicated physics) is to up the number of times you run your physics each frame, making the error smaller, or to try to make the time steps identical to reduce the error to 0, or as close to it as possible.