Collision Method

If I understand correctly

- your sprite is also another rectangular
- your sprite always start from outside of any solid.


assume your sprite name "s" that contain x1, x2, y1, y2 for the current position and x3, x4, y3, y4 for new position

The best method I can think of is:

in case size of your spirte is equal or less than solid
1. defind the line of movement of sprite
so you get 4 line (s.x1, s.y1, s.x3, s.y3) , (s.x1, s.y2, s.x3, s.y4) , etc...

2. defind the direction of the movement in 8 direction, north, north-east, east , etc...

3. deduce the impossible edge such as the direction is north-east so the north and east edge of solid will not be possible to collie and also the south-west line of movement (from 1.) will not be possible to collie too

4. check all possible line as "line intersection", I can't remember the exact fomular but just only line intersection (no need to care where they intersect) is quite fast

sorry for my broken english.
and I hope this suggestion will be useful for you

Best Regards
Neon

The x1, x2, y1, and, y2 coordinates are just used for a bounding rectangle. Unfortunately, I don't understand what you mean by my sprite name "s", so I don't fully understand the rest of your post.

What kind of game are you making? It could be easier if you're making anything but a side scroller.

I personally also find your choice of variable name very poor. Why not something like, X, Y, Width, Height? Or encapsulate x and y into a Vector struct, then have 2 structs for Min and Max.

"s" is just only the name, like your struck name "solid"

is my example s is represent of the object that you want to detect collies

Your method is fairly good, with a few exceptions.

Indeed, your variabele names aren't very descriptive. x, y, widht and height would be better, as GroZZleR already mentioned. And while we're at it, why use a nameless struct? You could write a real struct/class for it, named Rectangle or such, and give it a proper constructor, a collision check function, and other usefull functionality. That means that, whenever you need to do rectangle-rectangle checks, you don't have to write the collision code again.

As for the collision response, it's ok, but could be done a little bit better. Right now, you don't allow a rectangle to move if it ends up intersecting another rect. This means that there will often be a gap between them. Why not check how far that rect can move, and only move it so, that it ends up just outside the other rect?

An easy approach would be to determine how far that rect intersects with the other rect on each of it's four sides. On the side that it intersects least, you can push it out, and since you know how deep it intersects, and on which side, that's pretty easy to do. This depends a bit on what results you want, of course, and on the situation, but it'll probably suffice.

Thanks everyone. I changed the struct and changed the variables to x, y, width, and height.

@GroZZleR: I'm not using this for a side-scroller, I'm making a top-down-shooter.

@Captain P: I'll try your method, but just out of curiosity, why would there be a gap between the two rectangles?

With your method, gaps can happen, because you don't move if a move ends up in a collision. So, if there's 4 pixels between block A and B, and A wants to move 6 pixels towards B, they collide, after which the movement is aborted, so it's still 4 pixels away from B.

That's why I suggest checking how deep A sticks into B, and moving it out in the direction that it sticks in the least. Or, if that's important in your game, only push it back into the direction it came from - which is a little more complicated, so personally I wouldn't do it unless it's very important.

Oh, I understand now. Thanks for your help!