In terms of 2D or 3D?

I guess if you pretend each rectangle has two diagonals from corner to corner and test for intersection. This won''t work if one of the rectangles is also rotated.

hmm...

so say rectangle one is ((1,1) - (100,100));

so, the equation of the diagonal is y = MX + B

M is the slope, or Y2- Y1
------
X2 -X1

in this case, would be 1.
B is 1 (the offset from zero)
so the equation is Y = X + 1

rectangle two is (100,100) - (1,1)

in this case, Y = -X + 101

To test intersection, the equation is:

X + 1 = -X + 101

which simplifies to:

X = -X + 100
2X = 100
X = 50

Doublechecking:

Y = (50) + 1 = 51
Y = -(50) + 101 = 51

So yes, they do intersect, and they intersect exactly halfway through (X = 50).

Dunno how well any of this translates to computer programming, but just a idea I had

BTW you would need two diagonals for each rectangle, and you would have to perform two tests.

rectangle collision detection is female dog to say the least. if yoru rects can rotate, you have a major problem to contend with since most tutorials dont deal with that aspect. my algo handles it quite well though may not be optimal.

first off you will use two version of the bound box, rotated and unrotated. (this was done in an overhead shooter similar to subspace but withoutt he shooting part and ships could collide and not get destroyed so it was kinda like bumber ships)

this algo assumes:
1. that the unrotated version will match an unrotated sprite which makes sense.
2. that points are in 2d space, you could though adapt for 3d space (quite easily actually) once you understand the algo and the concpet behind it.

definations:
sprite1 is the sprite checking for collide
sprire2 is the sprite being checked with (i did it in a class fucntion)
all sprites store their own angle varible which represenst the anbgle at which they are rotated (obviously)
this technique makes more sense if you understand what is being done, which is basically converting coordinate space like in 3d camera transformations.

rotbox1: rotated bound box for sprite1
rotbox2: rotated bound box for sprite2
nonbox1: non rotated bound box for sprite1
nonbox2: non rotated bound box for sprite2
the algo:

1. find the non rotated version of the bounding box of sprite1
2. rotate the rotbox2 with the negeative angle that sprite1 is rotated (converts sprite2box into sprite1 coordinate space)
3. if any of the rotbox2 points are in the nonbox1, you got collision. (simple point in rect check)
4. now the reverse, get nonbox2.
5. rotate rotbox1 using the reverse angle of sprite2
6. if any or rotbox1 points are in nonbox2 then you got collision (simple point in rect check)


this works in the following cases:
1. both sprites are rotated
2. only one sprite is rotated
3. one sprite is totally inside the other sprite
4. actually all cases

i WILL NOT post code regarding this. the algorithm is pretty easy to code and should pose very little resistence. i will however clarify the algo if you need me to, since some of my expliaination may be fuzzy.



Edited by - a person on December 9, 2001 11:57:46 PM

The way I do it is check to see if any vertex of one rectangle is inside the other one. Not too robust, but has worked great for me so far If your rectangles are rotating, then its not so easy of course