Time Delta, collision detection - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Time Delta, collision detection (/thread-8068.html)
Pages: 1 2
Time Delta, collision detection - mk12 - Sep 3, 2010 01:18 PM
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?
RE: Time Delta, collision detection - Skorche - Sep 3, 2010 02:32 PM
The easiest way is to use a fixed size timestep that is small enough that this can't happen.
RE: Time Delta, collision detection - mk12 - Sep 3, 2010 03:23 PM
But then wouldn't it be frame dependant?
RE: Time Delta, collision detection - Skorche - Sep 3, 2010 04:25 PM
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.
RE: Time Delta, collision detection - mk12 - Sep 3, 2010 04:57 PM
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?
RE: Time Delta, collision detection - Skorche - Sep 4, 2010 09:59 AM
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/fix-your-timestep/
RE: Time Delta, collision detection - mk12 - Sep 4, 2010 10:32 AM
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?
RE: Time Delta, collision detection - Skorche - Sep 4, 2010 11:20 AM
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.
RE: Time Delta, collision detection - mk12 - Sep 4, 2010 12:59 PM
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):
RE: Time Delta, collision detection - AnotherJake - Sep 4, 2010 06:05 PM
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/Animation/TimeBasedAnimation.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.
RE: Time Delta, collision detection - mk12 - Sep 4, 2010 07:02 PM
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?
RE: Time Delta, collision detection - AnotherJake - Sep 4, 2010 07:16 PM
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.
RE: Time Delta, collision detection - mk12 - Sep 4, 2010 07:23 PM
I am using a display link. But wouldn't my hybrid method I described work? Because the physics updating is my own code.
RE: Time Delta, collision detection - Skorche - Sep 4, 2010 07:58 PM
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.
RE: Time Delta, collision detection - AnotherJake - Sep 4, 2010 08:37 PM
(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.