Sign in to follow this  
KG_Brad

Collision Method

Recommended Posts

KG_Brad    134
I was curious to see if my collision detection method was efficient. What I like to do is store solid tiles in a struct that looks like this:
struct
{
     int x1;
     int x2;
     int y1;
     int y2;
} solid[MAXTILES];
When a sprite moves, the computer checks to see if it is about to move into a tile stored in that struct. If so, it doesn't move. If not, it moves. Is this a good method?

Share this post


Link to post
Share on other sites
Neon2302    122
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

Share this post


Link to post
Share on other sites
KG_Brad    134
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.

Share this post


Link to post
Share on other sites
GroZZleR    820
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.

Share this post


Link to post
Share on other sites
Captain P    1092
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.

Share this post


Link to post
Share on other sites
KG_Brad    134
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?

Share this post


Link to post
Share on other sites
Captain P    1092
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this