Collision detection between a rectangle and line

[kake_fisk]

How can i check if a rectangle (the player) have collided with a line?

[JVene]

It may seem odd to read this, but it's more involved than a post can answer.

There's a lot that would need to be known about the nature of timing in your application, how you deal with "overshoot" in such collisions.

While it's simpler in 2d than 3d, a good answer to your question would comprise a chapter or two.

Here's an example of some of the thought process so you can visualize why.

Say your player is in motion, such that when viewed "from above" (typical 2D) it's moving diagonally toward the upper left. The line to be tested is just in a little from the right edge of the display, and we can see from the travel path it will collide with the line about 2" down from the display top.

Now, how fast is the rectangle moving? How fast is the display updating?

Let's say we let things proceed until the rectangle is very close by not yet collided with the line. We can "tell" this by simple observation, knowing it's about to happen with our observation.

What happens next is important. If the rectangle's motion is fast, and the display rate is slow, we can tell that the rectangle will exceed the line by the next frame. It will travel farther than the obstructing line, in which case we'll need to make a judgement.

Now what? How are we going to respond? Is the objective to "bounce" the player path, or explode?

There could be 3 cases here.

It could be the rectangle has just touched the line - a perfect contact, if you will.

It could be the rectangle's right side has crossed the line and passed it, but only about 1/10th or so of the rectangle has passed the line. A little correction to the position and we can "make" this work out ok.

It could be that the rectangle was moving so fast that it actually moved beyond the line by the time the frame cycled. We could miss the collision entirely.

This is typical of the kind of things collision systems deal with in 2d and 3d games. The math isn't so tough. Generating points of contact is a bit much, you have to make some particular trade-off choices there, and there are several types of contact systems that tell you if the rectangle touched by one of it's corners, it's side, has exceeded the intersection (so we have to correct) - etc.

I've not even gotten to the real guts of it and already you can see I've started a chapter.

There are books on collisions, as well as game engines.

[_Superman_]

You can do this using Windows GDI.

Use the LineDDA function to get all the points on a line.
Then you can use PtInRect function to check if the point lies within the line.

This could be rather slow though especially if it is being used for a game.

[kake_fisk]

Oh, sorry if I posted too little information.
My game is a 2D top down game. It has very simple rectangular sprites.
The blocks are not moving (not really).
I'm just not so good in math and i couldn't find anything on Google.
Did i forgot to mention that all lines are straight, no diagonals.

Edit: I have all the coordinates of the lines and rectangles in an array, so that's already fixed.

[JVene]

Ah, then it is quite simplified

_Superman_'s approach would work, but if you don't even have diagonals, and if there's no fluid motion (for example, it's stepped motion in response to keystrokes), then you can use some simplifications over that.

The two endpoints of a line will tell you if it's vertical or horizontal. If it's vertical, you're mainly interested in knowing if the sides of the rectangle match or exceed the x coordinate of the line. Horizontal, you're checking y coordinates.

It's simplified a little, conceptually, if you're comparing the previous rectangle position with the new one, so you can have a sense of direction. If, for example, you know the rectangle is moving up, and in the previous position the line was above the rectangle, you're checking for collision of the top of the rectangle against the line's y coordinate. Similarly rotated for each of the 4 directions.

[kake_fisk]

Well, I still have a problem understanding, sorry.
But I think I can simplify this even more.

I have stored the objects Bounding boxes like this:

GameObject& a = obj_player;
GameObject& b = obj_leftblock[i];

You can get the x, y, width and height properties by doing this:

std::cout << a.x << " " << b.width << endl;

The reason why I want this collision checking is to only let the player be able to step over the object if he's coming from left towards right.

If he collides with the wall in any of the other directions he'll stop.
Don't worry, I'll write all the code for stopping and passing myself.
I just need help with the actual collision checking.

All game objects are 32x32. And here's how I do normal collision checking.
Where a is the player and b is the wall.

for (int i=0; i<(int)obj_wall.size(); ++i)
{
    GameObject& a = obj_player;
    GameObject& b = obj_wall[i];
    if ((a.x + a.width > b.x+1) && (a.x < b.x + b.width) && (a.y + a.height > b.y+1) && (a.y < b.y + b.height))
    {
        obj_player.hSpeed = 0, obj_player.vSpeed = 0;
        snap_to_grid();
    }
}

So I need 4 if statements to check if it has collided with one of the sides.
If he collided from left towards right, it'll let him by, else stop him.

Do you understand?
Tell me if I need to explain better or if there's something that's a little confusing.

[nuzzle]

[QUOTE=kake_fisk;1847415]If he collided from left towards right, it'll let him by, else stop him.

To detect whether collision is from left or right, in addition to the collision point you need to know where the "entity" was before it collided. This allows you to decide whether it crashed in from the left or from the right. It's determined by the x-position of the "entity" immediately before and at the crash.

To express it differently. In addition to the "entities" positions you need to keep track of their directions.

[kake_fisk]

Oh, that's no problem.
The object has a xprevious and yprevious property that updates automatically.

[nuzzle]

Oh, that's no problem.
The object has a xprevious and yprevious property that updates automatically.

Well then you're done aren't you?

As I understood you, you were able to identify collisions right? Then when you have a collision you only need to check where the colliding "entity" was the moment before to decide whether it came in from the left.

[kake_fisk]

Ohh, that's a smart solution.
It worked like a charm. Thanks.

I'm sorry for explaining so bad in the first post.
Thanks to everybody who posted in here.