Should games rely on frame rate only?

Question

Hello, I would like your suggestion about this problem...

To make it simple, I'll consider only the x axis.

Image an object in position 10, and its width also 10 units, which is moving forward 100 units per second, and due to low frame, on each update it should move 80 units.

After the first update is called, its position is now 90 and there is another object of the same size in position 120.

The next update, will move the object to position 170. Considering that I need to implement collision detection, calculating the collision before or after Update, none will work.

Now comes a simple question...

What to do in this case?

Do something like:

Position start = destinationPos - currentPos;
for (int i; i < start; i++)
    if (IsColliding(movingObj.Position + i, staticObj))
        //do the colliding stuff here

I don't like this solution, it may be okay for this case, but what if you have x, y, z and a lot of moving objects?

Another solution that I thought would be good, but I'm not sure if it's reliable, is to have another thread doing all this calculations in a loop.

This thread would be something like an infinite loop, and on each iteration I would calculate the elapsedTime which I believe would be very small and keep moving and calculation the collisions, and the rendering thread, which would be much more slower, would get the current state of the objects and just render it.

What you guys think?

Answer 1

This is a problem which, fortunately for us math boneheads, has more or less already been solved. The issue you're describing is solved by dynamic collision detection, which is used to determine if two objects collided between frames, and for certain kinds of collisions can even tell you exactly when the collision occurred, so you can update the state of the world correctly.

If you are not particularly interested in implementing the collision deteciton algorithms yourself, I would look into using a library that already does this sort of thing:

• Bullet physics engine
• G3D
• Geometric Tools

One of many good books on the subject is Real Time Collision Detection.

Answer 2

Mike Daniels touched on this, but your answer is no: you do not want to treat your objects as moving in discrete "bursts". Let's have an example in 1d: A car starts at x = 0, and accelerates 2 units/sec^2 in the forward direction. You would not recalculate the velocity and position at each frame. Instead you would use some simple calculus: velocity is the integral of acceleration, and position is the integral of acceleration. Thus v = 2*t and p = t^2. All you would then do is substitute for t based off how much time has passed since the initial condition.

Now suppose you have a second object at position 100, accelerating at -3 units/sec^2. Then its velocity is -3*t and its position is 100 - (3/2)*t^2. Solving for when the 2 positions equal each other, we can see that they collide when t = 40.

Using equations, then, you could see if things collide between frames. There are several frameworks that will do this for you even, but it's important to have a basic understanding of how it works.

Answer 3

This is kind of a side issue, but you may well find it's worth decoupling your logic update rate from the game's framerate and having a fixed time step for the physics and logic. It makes a lot of physics and collision stuff a lot simpler, and stops things from exploding when the framerate drops.

Glenn Fiedler's site has an example of an game loop that works this way. Personally, I'd always go with fixed rate updates given the choice. It just simplifies so many things, particularly around physics.