-3
\$\begingroup\$

I was wondering if collisions are usually calculated the exact moment an object is moved or if it is calculated in the game loop. I haven't been able to find anything on this.

Thanks

\$\endgroup\$
1
\$\begingroup\$

Almost everything happens in the game loop somewhere, so that distinction is a bit moot.

What you seem to be asking is "when you change the position of an object, do you check for collision there, or do you check for collision later." It depends on the specific needs of your game, but in general it's probably better to do the calculation later.

Code that sets an object's position doesn't always have access to all the other potentially-colliding objects. For example, if you're thinking of doing the collision checks inside setPosition:

void GameObject::setPosition(float x, float y) {
   m_x = x;
   m_y = y;
   // ...check for collisions here...
}

That will require GameObject to have access to every other GameObject, which is not generally a great design. Right there, that answers your question for you.

But let's say for the sake of argument GameObject does have this access, or that you're thinking instead of doing something like:

someObject.setPosition(newX, newY);
// ...check for collisions here...

That's also not a great idea. It's highly likely this snippet of code isn't the only place object positions get updated, and indeed any given game object might have its position updated more than once during any given update frame. If that's the case, you'd be wasting time doing a bunch of extra collision detection tests (only the last one will actually matter).

Further, if you're doing the collision detection you may as well do the collision response. Collision response involves moving things, which involves setting positions, which if you're using the first setPosition up there, is causing recursive collision detection and response cascades that will either deadlock your whole frame or at least kill your frame time. You'd have to cart around a bunch of state about which objects have been checked for collision response everywhere you might trigger response by moving objects, and it will get ugly fast.

Finally, it's generally preferable to do operations in bulk. Dedicating a whole slice of your update to loop doing collision detection once for all objects can be far more efficient than trying to sprinkle it "randomly" around the frame in a way that completely negates any gains to be had from cache-coherent access to the full set of data (all the objects).

So in general, you should allow objects to have their desired positions determined. Then, you should check for collision between all objects all in one go, and you should resolve collisions between all objects all in one go, adjusting everything to final positions afterwards.

\$\endgroup\$
1
\$\begingroup\$

Collisions are always calculated in the game loop, but you can do some things to just check collisions between a bunch of items instead of checking the interactions between all the objects array (n^n). First of all, i strongly recommend you to research/implement a quadtree based collision technique (great doc here), limiting in this way the number of elements to calculate.

After that, you can use other techniques like calculating the "position mesure" or firing webworkers/threads

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.