Time Delta, collision detection

Member
Posts: 30
Joined: 2010.08
Post: #1
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?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #2
The easiest way is to use a fixed size timestep that is small enough that this can't happen.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 30
Joined: 2010.08
Post: #3
But then wouldn't it be frame dependant?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #4
No. This is what a lot of games do. They have the simulation run at a constant rate (often 60Hz) and have the graphics draw as fast as possible.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 30
Joined: 2010.08
Post: #5
But how would I implement that though? You don't mean separate threads do you? And by as fast as possible you mean V-synced right?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #6
V-sync is a good idea if you can run faster than the display's refresh rate. No use drawing frames that you can't see and wasting battery power. Otherwise it slows things down.

As for using a fixed size timestep for you logic, I mean like this: http://gafferongames.com/game-physics/fi...-timestep/

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 30
Joined: 2010.08
Post: #7
The final touch part in that article confuses me. Like what is integrate( currentState, t, dt ) supposed to do ? And what is a "State" type?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #8
The state is referring to a snapshot of the game world at any given time. It's not really a type per se, but an abstraction they are using in their pseudo code.

Integrate is a calculus term. In this case means to update the velocity/position of all the objects.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 30
Joined: 2010.08
Post: #9
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):
Code:
double currentTime = hires_time_in_seconds();
State state;
double maxdt = 1.0 / 60.0;

while ( !quit )
{
    double newTime = hires_time_in_seconds();
    double dt = newTime - currentTime;
    currentTime = newTime;

    while (dt > maxdt) {
        state.physicsStep(maxdt);
        dt -= maxdt;
    }
    state.physicsStep(dt);

    render(state);
}
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #10
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.

There is another explanation of the fixed rate thing, which doesn't discuss the state interpolation technique, just the fixed rate part: http://www.sacredsoftware.net/tutorials/...tion.xhtml

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.
Quote this message in a reply
Member
Posts: 30
Joined: 2010.08
Post: #11
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?
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #12
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.
Quote this message in a reply
Member
Posts: 30
Joined: 2010.08
Post: #13
I am using a display link. But wouldn't my hybrid method I described work? Because the physics updating is my own code.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #14
The state is just the collection of values you store for your game.

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.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #15
(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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Optimize the collision detection alaslipknot 1 2,690 May 12, 2013 08:02 PM
Last Post: SethWillits
  Collision detection tutorial ThemsAllTook 7 22,613 Nov 5, 2011 05:20 PM
Last Post: SethWillits
  Help with Collision Detection..(i'm almost there) carmine 1 4,624 Jun 29, 2011 12:33 PM
Last Post: ThemsAllTook
  Collision detection for pinball game johncmurphy 0 4,754 Sep 6, 2009 02:46 PM
Last Post: johncmurphy
  Phases of Collision Detection Ingemar 5 7,564 Aug 24, 2009 06:11 AM
Last Post: Skorche