Pong Collision Detection question

[Embrace_It]

Atm, I'm making a Pong Clone. While building the game up from strach, I'm reading articles about collision detection. The following is the collision detection from Aaron's Game Programming Tutorials:

// Check to see if the ball is going to hit a paddle
bool CheckBallCollisions(Entity& paddle)
{
    // Temporary values to keep things tidy
    int ball_x = g_Ball.screen_location.x;
    int ball_y = g_Ball.screen_location.y;
    int ball_width = g_Ball.screen_location.w;
    int ball_height = g_Ball.screen_location.h;
    int ball_speed = g_Ball.y_speed;

    int paddle_x = paddle.screen_location.x;
    int paddle_y = paddle.screen_location.y;
    int paddle_width = paddle.screen_location.w;
    int paddle_height = paddle.screen_location.h;

    // Get which paddle we're checking against
    if ( paddle.screen_location.y == PLAYER_Y)
    {
        // Check to see if ball is in Y range of the player's paddle.
        // We check its speed to see if it's even moving towards the player's paddle.
        if ( (ball_speed > 0) && (ball_y + ball_height >= paddle_y) &&
            (ball_y + ball_height <= paddle_y + paddle_height) ) // side hit
        {
            // If ball is in the X range of the paddle, return true.
            if ( (ball_x <= paddle_x + paddle_width) && (ball_x + ball_width
                 >= paddle_x) )
            {
                return true;
            }
        }
    }
    else
    {
        // Check to see if ball is in Y range of the computer's paddle.
        // We check its speed to see if it's even moving towards the computer's paddle.
        if ( (ball_speed < 0) && (ball_y >= paddle_y) && (ball_y <= paddle_y +
              paddle_height) )
        {
            // If ball is in the X range of the paddle, return true.
            if ( (ball_x <= paddle_x + paddle_width) && (ball_x + ball_width >=
                  paddle_x) )
            {
                return true;
            }
        }
    }

    return false;
}

Now assume that we move the ball, then check for collisions, and that the ball has a speed of 10 pixels/second towards the right. Also, imagine that the ball is currently 9 pixels away from a paddle (in the x-direction). The next time we move the ball, this function registers a collision, since the ball moves "into" the paddle. Upon returning from the function and seeing that it returned true, we inverse the xspeed to make it go in the opposite direction, so the next time we move the ball, it is moving towards the other end of the screen.

What I don't understand is that you would see the ball bounce off 9 pixels too early, right? Correct me if I'm wrong, but if this is the case, what would/could be a solution? Maybe set the ball to move the 9 pixels instead of 10? Then afterwards move it normally with the right speed?

 

[Samael88]

Have you changed the ball widht in any way? Or the ball position compared to where the image is at?

Those are the most common misstakes I do when it comes to these things.

 

[Slapshot136]

the way that you described it yes, the ball would bounce a bit early, but this check should run fairly fast (30+ times a second?) so that it's not so noticeable

a slightly better way would be to calculate that the ball would move 9 to the right, hit the wall, and then move 1 to the left, basically calculate where the ball should be as a result of the collision as well as what it's new trajectory should be

 

[Embrace_It]

@ Sameal88: I actually havent made the ball graphic yet but I'm taking into account the width of both the image and the ball itself.

@ Slapshot136: I was playing around with that idea, but I'll have to take into account that it could hit a wall as well, and suppose the ball is 5 pixels away from a paddle, the it would stay in the same spot (moving 5 to the left, then 5 to the right) and then start moving in the opposite direction.

Collision detection sure is hard

 

[Samael88]

Pong collision could be made fairly easy you know

If you want the ball to travel in a constant value, all you need to do is to invert the values every time the ball hits something
Like, if it hits the upper wall you would want the Y speed value inverted and the, if it's hit's a paddle you would want the X speed value inverted. It is fairly easy to do when I come to think about it
Even tho that would give a rather predicable game

I can't seem to find anything in that code that could cause it. Have you checked that your not putting the code in the wrong order?

Like this for example:
Move();
Collision();
Show();
That would be a horrible misstake to do

 

[Embrace_It]

Pong collision could be made fairly easy you know

Yeah

Even though that seems to be true, lets assume that the call order is:

Collide();
Move();
Update()/Show();

Moving at 10 (x- and y-speed) the ball is 9 pixels away from the top wall, and is moving towards it. Now because 9 - 10 < 0 this would make Collide() return true, and we would change the sign of the y-speed. Now should the update function render the ball just on the edge (max(y-yspeed, 0))? Or should it do nothing? The next time the ball moves it should be going in the right direction.

Am I making sense here or am I missing something?

 

[Samael88]

If the ball is moving at 10 pixels, then I don't see why you have the edge so that the ball is able to get 9 pixels from it? I would just move the wall that 1 pixel if that could. Does that work?
I always try to find the easiest possible way to fix a problem just not to make it to complicated.

 

[Slapshot136]

moving the wall.. sounds like a bad idea, sorry, the wall will not be in the way 99% of the time, this is only for when there is a collision, otherwise the ball will travel like normal

using the time and speed that the ball is going find the position, and if there is an obstacle in the way, then find the time it would take to reach the obstacle, after which you would have a new time and new speed, and you would re-calculate the position that the ball should be in (after bouncing)

i hope i worded that in a way so that it will be easy to code

 

[Samael88]

@Slapshot: That could actually work, but that will be a bit more complicated than it sounds.

Then you would need to basically check it pixel by pixel.

Btw, I have found out what might be the error

Let's see if I get this right:
Do you by any chance have the collision and the movement together?

If you do you probably have this:
if (ball hits wall)
move ball this and that.

if (ball does not hit anything)
move ball this and that.

then it would move the ball twice if it hit the wall, thus making your problem.

Other than that it should not be any possible problems to it what I can think of right now

Usually it should be this btw:

1. balls is 9 pixels from the wall.
2. ball moves into the wall, and the function changes the direction of it.
3. Ball moves 9pixels away from the wall.

Either you do that, or you move the wall 1 pixel and the ball should be able to bounce away. This could cause a bug to appear that makes the ball go into the wall, but that can be worked around with raising the "move per second" and lowering the "pixel moved" ratios, if you know what I mean

 

[Embrace_It]

@ Slapshot136: I did think about doing it that way, but I figured that it would be a pain in the *** to code considered what you have to take into account when the ball hits just right or left of a corner. Imagine if the new trajectory and speed would cause the ball to bounce again.

@ Samael88: Sorry, but I haven't started coding that part yet, but I can assure you that it would not be a problem if I had I see what you mean by "moving the wall". I can set the wall's width and height to a number like 60 which, if the ball's speed is 10 would never create the situation that we are discussing. One problem though, is the fact that I intend to increase the ball's speed slowly over a period of time, which would mean that I have to increase the speed by at least 5 every time.

Well, I think we are getting there, so I'll try out a few things as soon as the game has been developed enough for me to do so, and I'll see how it goes. Ofc, feel free to feed me some more great ideas

 

[Samael88]

I just had a great idea I don't know if it has been brought up before, but here is goes:

Say you have a speed of 10.
First you need to check the distance from the wall, if it is less than ten then you could use a certain function for that scenario.

Say the distance is 5 from the wall, still a speed of 10.
first you calculate where the ball will hit the wall after moving a distance of 5, then you take the projection you get there and use it to calculate where the ball will be 5pixels later

I hope you get what I mean

 

[Embrace_It]

Hi Samael88,

Sorry for not answering for such a long time, but I've been busy

I think that Slapshot136 already proposed a similar idea, and it seems like a complicated idea. In calculating the future position of the ball after a collision with something, I have to bear in mind that the ball can almost instantly collide with something else. A wall and then a paddle for example.

I've thought long and hard about it, and I've decided to try and make the game scene so that a strange situation like this will never happen. That is, I'm gonna make the width and height of the playing area so that it will always be 10 pixels away.

As always, thanks for your great amounts of help and advice. I'll be sure to post the finished project here when it's done :thup:

 

[GooS]

Havn't read all code nor all posts but a simple rect collision detection should suffice:

bool rectCollisionDetect(args)
{
bool within_x_range = (ball.x > paddle.x && ball.x < paddle.x + paddle.w);
bool within_y_range = (ball.y > paddle.y && ball.y < paddle.y + paddle.h);
if(within_x_range && within_y_range)
   return true;
return false;
}

using a rect struct

struct rect{
  int x;
  int y;
  int h;
  int w;
};

w = width
h = height

shouldn't it? If you don't have a rect struct then you should be able to get x,y,h,w values some other way, even if it's but as a magic number somewhere
within the code.

Edit:

Read the real question now, sry. Well if it's the left paddle you should take its (x+width) - ball.x on collision and move the ball to that x, however that would alter the speed and it might look abit odd, depending on how fast the ball actually is moving, it might not even be noticable.

//==GooS