   Collision balls
  I'm making a 2d game that I'm sure you have all seen before.  Several balls will bounce around the screen, and the user's goal is to move his ball around the screen and to avoid hitting the other balls.After a certain amount of time, another ball is added.  This process continues.I am using a very simple collision test where the distance between two balls in calculated using their coordinates.  If this distance <= the sum of their radii, a collision is detected.Will I need to write separate code to account for every possible collision between any two balls?  That is, do I need to write code for if ball1 hits ball 2, if ball1 hits ball 3, if ball1 hits ball4 and then if ball2 hits ball3 and if ball2 hits ball4 and so on?  Or is there a way to perform all of these calculations at once.Additionally, i need to account for the fact that the number of balls on the screen will change at any time.  I need to choose not to test those balls that do not exist yet.How can I account for all of these problems?  Thank you.   
  The typical approach would be to use a nested loop. Say the balls are stored in an array; the loop to test all unique pairs for intersection might look something like this (note: no guarantee of correctness):for (int i = 0; i < num_balls - 1; ++i) {    for (int j = i + 1; j < num_balls; ++j) {   if (intersected(balls, balls[j])) {  // Do stuff...   }    }}As for testing only currently active or existing objects, how to handle that depends on how your objects are managed and stored.   ;  Hey,Ok im a little bit of a noob at game dev but have some knowledge with C#, but isnt their a easy way to detect the balls if they belong to a class? Becuase you know exactly what class the ball is (obviously instantiated with a different unique id) but to detect a collision you dont really need to know the id? you should just know that if (ballClass.Size <= currentDistance){  //Then collision happened}If you not using object orientated programing then im probably little use to you. also im not 100% sure how right i am as im still new to game dev but just thought about your question and how i would approach it.   ;  alright jyk.  That's exactly what I was thinking of doing.  Thanks for the help.@komatous.  That's basically what I described above.  But you do need to consider the size of both balls involved in the collision, not just one.Thank you for the ideas.   ;  Why did you use ++i and ++j as opposed to i++ and j++?It seems like using your method that we won't test some of the different balls that could collide.  Won't the 0th i ball be ignored and the 0th and 1st j ball be ignored?Because, in essence, doesn't your code say that i will start at 1 and j will start at 2?   ;Quote:Why did you use ++i and ++j as opposed to i++ and j++?Although the example is technically pseudocode, the idioms I used are those of the C++ language. In C++, the pre- and post-increment operators have different behaviors. Conceptually at least, the post-increment operator does more work than the pre-increment operator (due to the fact that the value prior to the increment is returned). Whether this equates to more 'actual' work depends on the circumstances, but IMO it's more clear conceptually (and more expressive of intent) to use pre-increment unless post-increment is actually what you want. (Note that when post-incrementing the loop counters, the return value is ignored, so on a conceptual level at least you're doing unnecessary work.)Quote:It seems like using your method that we won't test some of the different balls that could collide.  Won't the 0th i ball be ignored and the 0th and 1st j ball be ignored?Because, in essence, doesn't your code say that i will start at 1 and j will start at 2?I always find the 'unique pairs' nested loop hard to get right off the top of my head, so I can't guarantee the example I posted is correct (although it looks right to me). I'll see if I can explain the logic behind it though.Let's say you have a container of three objects, and you test for intersections between these objects using a nested loop, like so:for (int i = 0; i < 3; ++i) {    for (int j = 0; j < 3; ++j) {   if (intersected(objects, objects[j])) { ... }    }}If you step through this nested loop, you'll see that the following pairs of objects are tested:0:00:10:21:01:11:22:02:12:2Note, for example, the pairs 0:1 and 1:0. This is the same pair (just ordered differently), so the second time we encounter it we've actually already tested these two objects for intersection, making the second test redundant. Generally speaking, a naive nested loop like the one shown above will perform many unnecessary intersection tests.The form of the loop I used in my example (assuming I got it right) iterates over the objects in such a way that no redundant checks are performed. (If you're unsure how this works, try stepping through it while keeping track of the pairs that are tested - you should see that each unique pair is tested exactly once.)   ;Quote:Original post by zoner7Why did you use ++i and ++j as opposed to i++ and j++?In a case like this, it's just a matter of style.  In some cases, like maybe if i is an iterator, ++i will be more efficient because it will just increment i and then return the result.  i++, on the other hand, must store the value of i, increment i, and then return the old, unincremented value of i.Quote:Original post by zoner7It seems like using your method that we won't test some of the different balls that could collide. Won't the 0th i ball be ignored and the 0th and 1st j ball be ignored?Because, in essence, doesn't your code say that i will start at 1 and j will start at 2?No, look at it carefully.  i gets initialized to 0, and then j gets initialized to i + 1, which turns out to be 1.  Basically he made a quick optimization and cut the number of comparisons in half.  If you were to do:for (int i = 0; i < num_balls; i++) // you could also do ++i{    for (int j = 0; j < num_balls; j++) // you could also do ++j    {   if (i != j && intersected(balls, balls[j])   {  // do stuff   }    }}You would compare balls against each other twice, because you compare balls 3 and 7 (I just picked those two numbers randomly, the same thing applies to any two numbers) against each other when i == 3 and when j == 7, but then you compare them again when i == 7 and when j == 3.  Rather than be redundant and do the comparisons again, we can easily make a small modification to our for loops that will remove the redundant comparisons.[edit]NINJAAAAAAAAA'D!If you were to run jyk's original loop and if num_balls == 4, you would get the following pairs of i and j.i:j0:10:20:31:21:32:3See how there are no duplicates?  Now if you were to run the un-optimized loop in my post, you get the following pairs of i and j.i:j0:0 // uh oh, we don't want to check if a ball is intersecting itself!0:10:20:31:0 // uh oh, we already did this, why are we doing it again?1:1 // uh oh, we don't want to check if a ball is intersecting itself!1:21:32:0 // uh oh, we already did this, why are we doing it again?2:1 // uh oh, we already did this, why are we doing it again?2:2 // uh oh, we don't want to check if a ball is intersecting itself!2:33:0 // uh oh, we already did this, why are we doing it again?3:1 // uh oh, we already did this, why are we doing it again?3:2 // uh oh, we already did this, why are we doing it again?3:3 // uh oh, we don't want to check if a ball is intersecting itself!See all the redundant comparisons?  If we just take out all those redundant ones, we are left with the results of jyk's original loop.   ;  alright.  I definitely understand how the function avoids redundantly checking collisions between two given balls.The thing that must be confusing me is when the i is increment when we use ++i instead of i++.I always thought that i++ was incremented when the loop ends and ++i was incremented when it begins...  Clearly I'm wrong.I understand what you were saying about the post operator taking i, making a copy, incrementing it and then iterating through the code with the copy.I'm just not sure how to put it all together. How does it work again?Thank you   ;  There are two operators associated with ++.  Post-increment and pre-increment.  Neither have anything to do with for-loops.  Post-increment (i++) means that you get the value of i, then you increment it.  Pre-increment means you increment the value of i, then you get it.  Try running the following:int i = 0;int j = 0;std::cout << "i++: " << (i++) << std::endl;std::cout << "++j: " << (++j) << std::endl;Sometimes you can use post or pre-increment and get the exact same end effect (like we've seen in the for-loops in this thread since we just discard the value returned by the operation).  However, pre-increment can be more efficient (though the compiler will usually optimize post-increment to be the same) since it doesn't require the compiler to store and then return the old, unincremented value.  The same thing applies to the -- operators (post and pre-decrement).   ;Quote:Original post by zoner7alright.  I definitely understand how the function avoids redundantly checking collisions between two given balls.The thing that must be confusing me is when the i is increment when we use ++i instead of i++.I always thought that i++ was incremented when the loop ends and ++i was incremented when it begins...  Clearly I'm wrong.I understand what you were saying about the post operator taking i, making a copy, incrementing it and then iterating through the code with the copy.I'm just not sure how to put it all together. How does it work again?Thank youIn a "for" loop, the order doesn't matter since the increment only occurs in the end of the loop. Think of it like this:int i = 0;while (i < 10){    // do something    i++;}i = 0;while (i < 10){    // do something    ++i;}They both do the same thing.   