Improving Collision System

[corey mason]

Right now i am checking for collisions with this:

bool checkCollision(float Ax, float Ay, float Aw, float Ah, float Bx, float By, float Bw, float Bh) {
    if(Ay + Ah < By) return false;
    else if(Ay > By + Bh) return false;
    else if(Ax + Aw < Bx + Bh) return false;
    else if(Ax > Bx + Bw) return false;
    return true;
}

Shown at checking for collision with bricks:

ballX += ballVX;
    for(int i = 0; i < BRICKS; i++) {
        if(bricks[i].alive == true) {
            if(checkCollision(ballX, ballY, ballWH, ballWH, bricks[i].x, bricks[i].y, bricks[i].width, bricks[i].height)) {
                ballVX = -ballVX;
                bricks[i].alive = false;
                DESTROYED += 1;
                break;
            }
        }
    }
    ballY += ballVY;
    for(int i = 0; i < BRICKS; i++) {
        if(bricks[i].alive == true) {
            if(checkCollision(ballX, ballY, ballWH, ballWH, bricks[i].x, bricks[i].y, bricks[i].width, bricks[i].height)) {
                ballVY = -ballVY;
                bricks[i].alive = false;
                DESTROYED += 1;
                break;
            }
        }
    }

shown at checking for collision with pad thing:

    if(checkCollision(ballX, ballY, ballWH, ballWH, myX, myY, width, height) == true) {
        ballVY = -ballVY;

        float temp = ballX + ballWH / 2;
        temp = temp - myX;
        temp = temp - 25; //40 = easy 25 = normal 15 = hard
        temp = temp / 10;
        ballVX = temp;
    }

variables related:

float width = 80;
float height = 20;
float myX = 300 - (width / 2);
float myY = 370;

float ballX = 50;
float ballY = 350;
float ballWH = 30;
float ballVX = 2;
float ballVY = -2;

BallVX is the balls X velocity and BallVY is the Y velocity (X/Y axis).

Now i would like to improve this but i don't know how?
I would like to have it consistent in terms of speed, it isn't right now.

[Disch]

I'm not sure why you think this needs improvement. Consistency with speed isn't really a good thing. You would want early outs so that it can run as fast as possible when able. To be consistent you'd have to have it run at its slowest always, which is bad.

[MrHutch]

The logic seems fine, really.

You could tidy it up by passing ball and brick objects to it, rather than a bunch of floats, I guess.

Edit: Comment above mine looks like spam. If it's still there when I get home I'll report/delete it.

[ResidentBiscuit]

Looks like you're always comparing every object with each other, which seems inefficient. After looking around, http://en.wikipedia.org/wiki/Octree might make it a little more efficient.

Though if you're not working with a large set of collidable items, this might just be a lot of work for little gain.

[BlackSheep]

Although since he is working in two dimensions, a quadtree would probably be a better data structure ;)

[ResidentBiscuit]

I wasn't sure if he was working in 2D or 3D, so I just posted the octree, since there's a link to the quadtree in the first paragraph.

[corey mason]

my main problem is when it comes from the side (left/right) it sometimes gets stuck, rapidly changing direction as it *should*, thus not moving out (getting stuck).

[ResidentBiscuit]

Hmm I think I had this issue awhile back with something similar. Unfortunately, I lost the program when my hard drive crashed, so I can't remember the solution completely.

Pretty sure what I did was made a bool for recent paddle collision (as I made a pong game), and set it true when it hit a paddle, and false when it hit a wall. This made it so the ball would only collide with the paddle once, until it hit a wall again. I'm sure you can modify this to fit your needs.

The issue I seem to remember had to deal with the ball getting "into" the paddle at high speeds, basically there would be a bunch of pixels touching the paddle as the ball was partly inside of it. This would cause a bunch of collisions to occur. The bool deal should fix it for ya.

[Texan40]

I used SFML to make a breakout clone too. For collision I used screen rectangles for broad areas and then a matrix of rectangles in the "wall" area. I just used SFML's own functions to find if the rectangles overlapped to do the collision.

the rectangle breakdown was something like this for a 925 x 520 game screen

open area top    = 925 x 40   { (0,0),   (925,0),   (925,40),  (0,40)    } // points clockwise from top left
open area bottom = 925 x 280  { (0,200), (925,200), (925,500), (0,500)   } // points clockwise from top left
left wall area   = 10  x 520  { (0,0),   (10,0),    (10,520),  (0,520)   } // points clockwise from top left
top wall area    = 925 x 10   { (0,0),   (925,0),   (925,10),  (0,10)    } // points clockwise from top left
right wall area  = 10  x 520  { (915,0), (925,0),   (925,520), (915,520) } // points clockwise from top left
brick wall area  = 925 x 160  { (0,40),  (925,40),  (925,200), (0,200)   } // points clockwise from top left
paddle area      = 925 x 20   { (0,500), (925,500), (925,520), (0,520)   } // points clockwise from top left

game ball        = 20 x 20
large game brick = 40 x 80
small game brick = 40 x 40

I could get "early outs" from the top two rectangles as there will never be a collision in either of them