# collision detection in the game loop (time question)

This topic is 3854 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have a question as to how time is managed when doing collision detection. I've come to the conclusion that somewhere in my game loop I have to determine at what time the next collision occurs. From there I determine whether or not that happens in the current frame and thus whether it can be ignored. But my confusion comes from what to do with the left over time for that loop. I have a frame independent game loop that looks something like the following:
float delta;
float lastLoopTime = (float)SDL_GetTicks();

while (isRunning)
{
delta = (float)SDL_GetTicks() - lastLoopTime;
lastLoopTime = (float)SDL_GetTicks();

secsPerFrame = delta/1000.0f;
while (SDL_PollEvent(&event))
{
//process events
}
updateTheWorld(secsPerFrame);
renderTheWorld();
}

Where abouts would the collision detection be handled? Does it matter? Say collision detection was handled just before updateWorld and the game determined that there was to be a collision in 0.5 seconds. However, the secsPerFrame is supposed to be 1 second. That would mean I would have to update the world up to 0.5s, resolve the collision i.e. changing the velocities of the colliding objects, and then update the world again for the rest of that 0.5s. But then what happens if the result of that collision means that there is going to be a different collision, that was unforseen until the first collision was handled, in another 0.1s time? So my confusion is that there could be lots of collisions to resolve in the space of the 1s frame, almost like there is a game loop inside the game loop in order to resolve all the collisions. My question basically comes down to this: Is this the way it's supposed to be done, or is there a completely different method which I'm unaware of? It just seemed like it got complicated really quickly. If there are other discrepancies from what I've written above, I'd be happy for you guys to give some alternatives. Cheers.

##### Share on other sites
Your answer requires some more information. Does your game really update every second? If so that is probably to slow for anything put an old school tile based game. Is your game 2D or 3D? How do you determine collisions? Do you use a physics engine? What you are describing to me may be the right way but I can not tell from your question. Give some more information and I will see if I can help out.
Happy Deving,
zach297

##### Share on other sites
Sorry, I guess it was a little vague.

I'm making is a 3D game using OpenGL and C++. It's actually a pseudo isometric helicopter shooter (3rd person) like the old Jungle/Desert Strike games. The collisions are primarily for detecting whether projectiles have hits objects, and not really for more physics intensive things such as objects bouncing objects off each other. I'm not using physics libraries.

My 1 second frame rate was for trying to illustrate an example but even if it was 1 thousandth of a second, the same issues would arise.

##### Share on other sites
If all you're looking for is to see if a bullet or projectile has hit a target and then have that target explode (or whatever) than the way you are doing it sounds fine. Just see if a collision will occur before the next update and pretend it has already happened. If a collision occurs in 0.5s have it happen now. This solution can get messy though if you are looking for anything other than explosions (like bouncing objects of each other). You might have to have something a little more robust though if you can't guarantee a consistent update rate. If what I say doesn't work don't be afraid to try something else.
Hope that helps,
zach297

##### Share on other sites
Some of my confusion has come from the game loop I am using. I should have taken the advice given to me once before and have a good read of http://dewitters.koonsolo.com/gameloop.html

This topic does get really complicated real quick, but there are some resources out there, such as http://www.nuclex.org/articles/xna-game-loop-basics#comment-1586. I'm going to have to do some serious reading before I can come up with some intelligent questions.

##### Share on other sites
One approach is just to do one step collision response, and defer the next load of collisions to the next frame. If you have a relatively sparse world and fast frame rate, you won't notice the slight problems this causes.

1. 1
Rutin
46
2. 2
3. 3
4. 4
5. 5

• 13
• 10
• 12
• 10
• 13
• ### Forum Statistics

• Total Topics
632991
• Total Posts
3009753
• ### Who's Online (See full list)

There are no registered users currently online

×