Delta Time and Acceleration

quick one this as my brain has stopped working due to the heat.

Assume I'm using delta time so that my sprite movement must be multiplied by delta each logic frame e.g. y=y+yspeed*Delta

OK, Let's say that yspeed is affected by gravity. Should I do yspeed=yspeed+GRAVITY*Delta each logic frame or should I miss off the *Delta bit. I'm pretty sure I have to use *Delta on the yspeed increase. (It looks OK on-screen)

Also take it a level further, let's say gravity was called ACCELERATION and it was a vehicle of some kind, and I wanted to increase the acceleration each frame, should I also change the rate of acceleration by delta each frame too? Probably...

Yes with all accelerations including gravity use speed=speed+acc*dt

For constant rate of acceleration yes use acc=acc+acc_inc_rate*dt

Be awares you will get varying results with changing values of dt - this is unavoidable. I avoid delta time like the plague for this reason.

You may use an average delta, calculated from the last couple of frames.

thanks. I run my logic at 200FPS and the delta is between those frames so it's pretty good.

Is there any reason to run the logic at such a high rate? Most monitors (especially now TFT is taking over) don't run any more than 60hz. Not that the monitor framerate is all that important but I don't really see the point in running the logic faster than the display.

Most console games run at 60fps internally.

With Naked War I went with 40fps for logic (simply to cater for lower spec machines) and haven't encountered any problems. I can tween to generate 200fps graphics if necessary.

Genuine question BTW.

An alternative method to using Delta Time if you need stability, is to run the logic once per millisecond.

So at 60fps you would run your logic 16 or 17 times per frame.

If you don't have a lot of computationally expensive stuff going on this might be an option.

The downside is that on low end systems you'll be doing more work per frame which may lower the framerate even more. But to avoid the hell of tweening? Well worth it I say.

sswift @ John: I'm already doing a version of what sswift describes. Basically I'm using Fixed Rate logic @ 200FPS thus 1 logic iteration every 5ms, with a bit delta time when the number of iterations per frame cannot be a whole number. This allows for smoother movement and more accuracy in collisions etc Don't forget I'm doing 2D games and smoothness (or lack of) is obvious whereas it's less of an issue in 3D games. If I could guarantee that the PC running my game had a refresh rate of 60Hz, like an NTSC console, or 50Hz like the Amiga (PAL), then I wouldn't bother with fixed rate logic OR delta timing. As I can't know the end user's Hz I choose to pick a high logic rate to improve the accuracy. Also if the video card fails to render quickly enough, the fixed rate logic makes sure that the same number of iterations occurs, thus collisions are still accurate. The first implementation of the fixed rate logic I saw (the "Retro64" method) acutally used 500Hz logic but that consumed too much CPU power for my last game, although my current game could probably handle that now... hmm hope that explains it enough. Delta time on it's own seems logical but the benefits of Fixed Rate Logic outweigh it imho.

I'm not sure how a high logic rate approves accuracy.

Surely it just increases the minimum spec for your game? So long as the logic is fast enough to be responsive - and anything above 30hz should do that - I don't really see what you are gaining. Maybe I'm missing something.

You can see how it improves 2D collisions right? If a fast moving object is tested for collision in a traditional manner (not a clever maths way), only say at 30FPS, it may "jump" over the object is supposed to hit whereas at 200FPS it's moving in smaller increments and is more likely to collide.

Also I read that when doing physics sims, you need a very high logic rate to keep them accurate (make's sense really as what FPS is reality? ;-))

Fixed Rate logic makes lot of sense for physics engines, that's why you have those substeps like for instance in havok without any renderupdates. Same goes for some 2d collisions as Grey said. But for anything else beside of such things i honestly didn't need it...so i would say it depends on the type of game if it's of real use.

Grey, why not do a better collision system? It seems a little exagerated to run game logic several hundred times per second. It's not dificult to predict where a 2D entity will be in say 100 milliseconds, so it's a simple question of testing whether the path is potentially blocked, and then do collision testing at a smaller stepsize with the potential colliders. Instead of running all the logic at a higher rate.

That really says it all, doesn't it? More *likely*, but not guaranteed.

"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.

My brain 'urts!

Well yes it is if you design the top speed of the object to fall in line with your logic frame rate so that it can never skip over things. This is a common technique in older games with fixed FPS like 25 or 50. Your point is true of course but I was pointing out that I wanted to do traditional collision instead of "a clever maths way" :-)

swift: good summary thanks. The method works for me so I'm sticking to it :-)

I've learnt in school: s=1/2gt^2 where g=9.81m/s^2 , v=s/t for the velocity and a=v/t for the acceleration.

Ever read Hal Clement's Schwere Welten? I think it's called Mission of Gravity in English but i'm not sure...

And i do have a little example for a physics explosion under http://spielwiese.marune.de/_uni/spielkisten/index.html by pressing the button "n" for nuke. ;O)