Time Delta, collision detection

My 2d OpenGL pong game is frame rate independent, using a delta time. But when the speeds are very high or the frame rate is very slow, the ball goes through the paddles and doesn't collide with them. What's the best way to deal with this?

So integrate would be updating the game with the given dt, but how do I implement or concretize this "State" snapshot? Does it represent another time? They're doing arithmetic on it so... I'm still kind of confused about that. Why is an accumulator and all that stuff needed? Why can't I just do as many steps at my fixed delta as I can fit, than do another step with what's left, because that delta be smaller than the fixed one, and the problem is with bigger time deltas anyway right? What I mean is (keeping to that article's pseudocode):

Quote:Why can't I just do as many steps at my fixed delta as I can fit, than do another step with what's left, because that delta be smaller than the fixed one, and the problem is with bigger time deltas anyway right?

Yeah, you could do it that way, which would be a sort of hybrid approach I suppose, but most physics engines assume a fixed step, so there may still be unexpected side-effects. Plus, you typically don't need to do the little part that's left over anyway. You can just draw whatever is the last update to fit. The interpolation thing in the gaffer article is just to get the most accurate snapshot of what is happening between the last two known updates. It will give you the very finest visuals, but it isn't usually needed in practice, unless you are a detail freak or have a particular need to use low update rates, such as for network multiplayer which might only send state deltas at 20 Hz. Besides, that state interpolation thing can add a significant amount of complexity to an otherwise simple simulation unless you really have things organized well.

The fixed update rate thing can be hard to figure out at first, but it is actually very simple once you get your mind wrapped around it. If you don't "get it" for a while, keep thinking about it until you do -- it's well worth the effort.

I tried doing that fixed time step on the gafferongames site, but it looked really choppy unless I had it at a multiple of the frame rate as the fixed time step, so isn't that defeating the purpose of time-based animation?

No, the main purpose of using fixed rate timing is to maintain stable physics integration and consistent collision detection (e.g. avoid exploding springs and quantum jumps through walls).

Yes, it can look a little choppy if you're looking at a simple scene, which is why you can add the interpolation technique if you're inclined to do the extra work. In practice, when you actually have a game going and things are moving around, you probably won't see the choppiness. Other devs use their own preferred step to help avoid the choppiness when not using interpolation. On the Mac I found 110 Hz seems to be a relatively even choppiness across most refresh rates. Again, if you want perfect, you need to add the interpolation, which like I said, isn't really necessary once you get a real game going with action all over the place.

If you're using an NSTimer, that won't help either. You'd have to use the Display Link for the interpolation to be effective. If you're not using interpolation then the NSTimer is effectively just as good as Display Link in my experience.

In the simplest possible example, your game's state consists of a single point and it's velocity. Updating (integrating) the state is as simple as adding velocity*timeDelta to the position. With a more complicated game state, you would be updating the AI, bullets, explosions, etc.

You could do a small step at the end to use up the rest of the time for the frame, but one of the benefits of running at a fixed timestep is that you get deterministic results. This means that every time you run 30 steps of your program with the same input, you'll get the exact same result. If you are letting the time step be based on the framerate, then that is something that you can't really control and will change the results every time. There are some algorithms that are much easier to implement as well if you can assume a fixed timestep to simplify things.

(Sep 4, 2010 07:23 PM)mk12 Wrote: I am using a display link. But wouldn't my hybrid method I described work? Because the physics updating is my own code.

Why don't you go ahead and give it a try? As Skorche pointed out, there are algorithms that benefit from a deterministic state, which you will be forfeiting, but that doesn't mean your hybrid approach won't work well for many situations. It won't work as well as a solid fixed time step, using interpolation for the drawn frame, but it should at least appear just as smooth for simple simulations and should avoid large deltas in extreme situations, which as you pointed out is a real killer.