[Beginner] Help with Bouncing Circles

[Cadisol87]

It's mass1 - mass2. It's the difference between the two masses. At the moment (and I didn't think I'd have to point this out explicitly) you are subtracting something from itself and it will always be zero. If the circles were to have different masses, you would use them there, but since they're all the same, you can remove (mass-mass) since it is 0.

Are you sure that I can just remove it? It would give me a different result...

The vectors (i.e. sf::Vector2f) are for the positions and velocities so that x and y can be conveniently in one variable. In some cases, calculation can be applied to the vector rather than directly to its components.

Well, I know that's more convenient to use vectors, but I think that Im going to that after I solved the problem with the sticky balls

[Hapax]

Are you sure that I can just remove it? It would give me a different result...

It wouldn't. You're subtracting zero. Removing that subtraction would change nothing. The (mass + mass) must stay, however, and leaving in the (mass - mass) won't harm anything so it's possibly safer to leave it there.

... the problem with the sticky balls

You have the vector values the wrong way around for the collision. X comes before Y.

Use:

if (Collision(
  sf::Vector2f(Ball[i].getPosition().x, Ball[i].getPosition().y),
  sf::Vector2f(Ball[j].getPosition().x, Ball[j].getPosition().y))

rather than:

if (Collision(
  sf::Vector2f(Ball[i].getPosition().y, Ball[i].getPosition().x),
  sf::Vector2f(Ball[j].getPosition().y, Ball[j].getPosition().x))

[Nexus]

The idea of vectors is not to unpack them to single coordinates at every opportunity

Why don't you simply write it like this?

if (Collision(Ball[i].getPosition(), Ball[j].getPosition()))

[Azaral]

Also, beware of changing the velocity of one before you calculate the new velocity of the other. If you do not, then you will not have a correct collision.

I did that, didn't I? 

I don't know, I was just throwing that out there.

[Hapax]

Why don't you simply write it like this?

if (Collision(Ball[i].getPosition(), Ball[j].getPosition()))

Or just do that :p Much simpler

[Cadisol87]

The idea of vectors is not to unpack them to single coordinates at every opportunity

Why don't you simply write it like this?

if (Collision(Ball[i].getPosition(), Ball[j].getPosition()))

Thanks, Nexus, I did that, but the problem is still not solved...

Here's the code so far:

for (int i = 0; i < ballcount; i++)
{
    for (int j = i + 1; j < ballcount; j++)
    {
        if (Collision(Ball[i].getPosition(), Ball[j].getPosition()))
        {


            Ball[i].move(newVelX1(xSpeed[i], xSpeed[j]) * dt,  newVelY1(ySpeed[i], ySpeed[j]) * dt);
            Ball[j].move(newVelX2(xSpeed[i], xSpeed[j]) * dt,  newVelY2(ySpeed[i], ySpeed[j])* dt);


            xSpeed[i] = newVelX1(xSpeed[i], xSpeed[j]);
            xSpeed[j] = newVelX2(xSpeed[i], xSpeed[j]);
            ySpeed[i] = newVelY1(ySpeed[i], ySpeed[j]);
            ySpeed[j] = newVelY2(ySpeed[i], ySpeed[j]);

        }
    }
}
 

Or did I something wrong with the order of calculating the new Velocities?

[Hapax]

I'm not sure I fully understand the code here, but why are you moving the balls in the direction they were travelling before the collision, after finding that they've collided? Could it be possible that the new speeds should be calculated before the balls get moved?

[Cadisol87]

I'm not sure I fully understand the code here, but why are you moving the balls in the direction they were travelling before the collision, after finding that they've collided?

The balls are moved to the new direction, not to the old. To make sure that they dont collide anymore.

Could it be possible that the new speeds should be calculated before the balls get moved?

If I understand you right, you mean something like this:

            xSpeed[i] = newVelX1(xSpeed[i], xSpeed[j]);
            xSpeed[j] = newVelX2(xSpeed[i], xSpeed[j]);
            ySpeed[i] = newVelY1(ySpeed[i], ySpeed[j]);
            ySpeed[j] = newVelY2(ySpeed[i], ySpeed[j]);
           
            Ball[i].move(newVelX1(xSpeed[i], xSpeed[j]) * dt,  newVelY1(ySpeed[i], ySpeed[j]) * dt);
            Ball[j].move(newVelX2(xSpeed[i], xSpeed[j]) * dt,  newVelY2(ySpeed[i], ySpeed[j])* dt);
 

or

            xSpeed[i] = newVelX1(xSpeed[i], xSpeed[j]);
            xSpeed[j] = newVelX2(xSpeed[i], xSpeed[j]);
            ySpeed[i] = newVelY1(ySpeed[i], ySpeed[j]);
            ySpeed[j] = newVelY2(ySpeed[i], ySpeed[j]);

            Ball[i].move(xSpeed[i] * dt, ySpeed[i] * dt );
            Ball[j].move(xSpeed[j] * dt, ySpeed[j] * dt );
 

Good Idea, but this doesn't solve the problem.

It's weird: sometimes, when two balls which stick together, collide with one single ball, the collusion seems to be correct.

If you have time, you can compile the code by yourself and watch it.

[Hapax]

The balls are moved to the new direction, not to the old. To make sure that they dont collide anymore.

Ah, I must've missed the whole "newVel" stuff in the move method. Probably because you used it the same again straight afterwards 

As for running the code, I might do soon, if I can work out which parts you're still using 

[Cadisol87]

Here's the Code. 

[Hapax]

It seems that the problem you were having is that you were assigning the new speeds as soon as you'd calculated them. This means that you calculate a new xSpeed and use the new one in the calculation for xSpeed[j]. It needs to be the same value for both calculations. You have to calculate all of the new velocities before assigning them - at the same time! It does show this in that tutorial :p

if (Collision(Ball[i].getPosition(), Ball[j].getPosition()))
{
        const float tempXSpeedI = newVelX1(xSpeed[i], xSpeed[j]);
        const float tempYSpeedI = newVelX2(xSpeed[i], xSpeed[j]);
        const float tempXSpeedJ = newVelY1(ySpeed[i], ySpeed[j]);
        const float tempYSpeedJ = newVelY2(ySpeed[i], ySpeed[j]);
        xSpeed[i] = tempXSpeedI;
        xSpeed[j] = tempYSpeedI;
        ySpeed[i] = tempXSpeedJ;
        ySpeed[j] = tempYSpeedJ;

        Ball[i].move(xSpeed[i] * dt, ySpeed[i] * dt);
        Ball[j].move(xSpeed[j] * dt, ySpeed[j] * dt);
}

It's still not perfect but they bounce now 

[Nexus]

You still haven't fully understood the vector abstraction. You should also use it as return type of your function.

In fact, you should always use vectors to represent 2D coordinates, and fall back to float only in exceptional cases -- not the other way around.

[Hapax]

His code is line for line from a tutorial so I thought it'd be better for him to actually see how the tutorial code works first so I fixed that. He should definitely start using vectors; not doing so is much more error-prone. However, if he'd have converted everything to use vectors and it didn't work, it would be harder to compare with the original tutorial to see what is wrong.

[Nexus]

That's true, but maybe the tutorial isn't the best one if it fiddles around with separate floats. I don't see a reason not to introduce vectors from the beginning... They don't add complexity, they reduce it.

Sometimes it's really amazing how simple the code becomes if you use the right abstractions... Same for trigonometry, for example. Since I've written Thor.Vectors, I'm hardly ever using std::sin() and std::cos()

[Hapax]

Your Thor library does look awesome. I'd almost certainly use it if I didn't want to work as low-level as possible to learn what's going on (I like maths etc.).
"Low as possible" means avoiding the lowest form - Windows programming. Thanks, SFML