Hi,

I've been spending the last week piecing together a simple game engine, using ODE for the physics and OpenGL for rendering. I needed a project to help me refresh my C++ abilities...it got a bit hairy in a few places

I'm a bit confused about the Update loops I've seen in some examples online (and in a few books).

They seem to be of the form
I currently have an EntityManager that looks after updating and rendering all the objects in a scene, so my the "main loop" of my game would be:


The only timed event I have at the moment is (which advances the phyics simulation), the new positions for game entities are returned in the EntityManager->Update() so they can be rendered in the correct locations with Render();

In the examples I've read that pass a delta_time variable it's used to update velocities/accelerations/animations:

e.g.


Do I really need to include something like this?

I don't really see an need using a delta_time because the 0.05 for the world step in ODE seems to take care of that.

I'd really appreciate if someone could tell me if I'm going wrong with this. My previous games have all been in J2ME and J2SE. I've simply used a wait() command on the game's Thread to ensure things run at a constant time or at least appear to be at a constant time to the player in those cases. So I may be looking at this from the wrong angle.

Thanks,

Anthony

If you're using a constant tick like you say you are with the physics engine and your update timing (which you *should* be doing), then strictly speaking, no you don't have to use delta time for your other (non-physics controlled) movements. However, I've found that still using delta time as a matter of habit is very convenient if I decide I want to change the ticks per second value for whatever reason. Your call...

Thanks for the reply AnotherJake, much appreciated!

I guess it would be something to include in my code even if I don't use it - all useful experience at the end of the day!

If you don't use a dt, then you have no way of knowing if your physics simulation will vary between fast and slow machines.

If you do use a dt, you can change it to 0.5 or 0.001 and easily see if some of your physics is accidentally non time based.

Quote:If you do use a dt, you can change it to 0.5 or 0.001...

Reubert, thanks for your reply, but is it not a bad thing to use variable time steps for physics simulations? Or maybe I've misunderstood what you are saying?

The dt should be the change in time from the last time the Update() was called right?

e.g.

Right, it should be a solid value for good physics integration.

I think what reubert was saying is that you can test to make sure you didn't screw up your physics coding by being able to vary the time step between builds. If you're developing on one machine then you'll get the same step in accidentally non-time based code because your machine is the same speed, but if it goes onto someone else's machine and you didn't do something based on time, then it'll whack out.

Since you're using a third-party physics library then this likely isn't a problem. However, not all libraries prefer the same step, so if you switch to something like Newton (which needs at least 60 ticks per second as I recall), there's another good reason to have delta time around.

Yeh sorry, I didn't make that clear. As AnotherJake said, you can vary the dt for testing purposes.

Thanks AnotherJake and Reubert for your replies.

It never occurred to me about different running speeds on different machines, I was preoccupied with getting it all working first - thanks, I'll include a more appropriate Update function in my code from now on!