i think you misread my post void*. the alogorithm i posted is for bounding boxes that ARE rotated. so the bound box stays exactly the same except its rotated. in other words you odnt need to make sure you bound boxes are aligned on any axis. yoru technique will not work with rotated rects at all. my system does not use the close enough and should work philosophy. its the exact bound box for a rotated sprite assuming the original bounding box was good. please next time read and understand the post and algorithm before assuming its as simple as you make it.
btw a clarification. you never need to generate a new bound box EVER. simply ensure you have an unrotated and rotated version of the bound box. (ie actually rotate the points of the bound box to match the angle of rotation of the sprite).
is this even making any sense at all? i will repeat again since it is a very important thing baout the algo. it is designed to take abitrary rectangles rotated to ANY angle and detect if there is a collision between them.
Collision between rectangles
quote:Original post by a person
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
To be accurate, these aren't all the cases.
The the rectangles can be positioned perpendicularly to form the shape of a plus sign (+ ). Here they do collide, but no vertex of one rectangle is inside the other rectangle.
It's true, though, that for most animations this case needn't be handled at all.
Besides, none of the original post and the replies before yours even mentioned rotation. You were the first one to bring it up. Did you honestly misread the question or did you just want to show-off?
Don't worry, I have the same problem.
I wrote a RotRect-RotRect collision detection routine too and I'm looking for a good place to post it. Only that mine really handles all cases, and it's even fast (this sentence can be used for you as a proof that I have your problem too).
Just try not to sound so conceited:
quote:
..my system does not use the close enough and should work philosophy...
Well, I showed you your routine is just close enough and should work. Is that always bad?
quote:
please next time read and understand the post and algorithm before assuming its as simple as you make it
Or should it be you that needs to read the original post better?
Regards,
Oren.
p. s: Blue*Omega, implement an idea like the one suggested by void*'s code. It's just fine.
Edited by - SkatMan on December 11, 2001 7:27:04 AM
Thanks for the defense, SkatMan...
a person: I was not trying to post source relating to your algorithm, I was trying to respond to the initial post. (Seemed more relevant). The reason I mentioned rotated-rectangle cases was because you had brought up that scenario, and I was trying to describe two (of several) choices for extending my source for those rotated-rectangle cases.
True, it doesn''t cover all bases, but the original post asked for the fastest way to detect if two rectangles are overlapping, not the most thorough way. Perhaps I should have made myself clearer about that, but I was hoping it would be evident that my code would be different from the other source/algo''s that were posted, seeing as how the original poster stated he was "just getting different opinions".
But I digress, I''m not trying to start a petty argument here, I''m just trying to explain myself a little further.
Blue*Omega: Assuming that the rectangles will not eventually rotate, my code should work fine... if you plan on rotating your sprites then you should go with something akin to a person''s or SkatMan''s algorithm.
"Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are and what they ought to be."
--William Hazlitt
a person: I was not trying to post source relating to your algorithm, I was trying to respond to the initial post. (Seemed more relevant). The reason I mentioned rotated-rectangle cases was because you had brought up that scenario, and I was trying to describe two (of several) choices for extending my source for those rotated-rectangle cases.
True, it doesn''t cover all bases, but the original post asked for the fastest way to detect if two rectangles are overlapping, not the most thorough way. Perhaps I should have made myself clearer about that, but I was hoping it would be evident that my code would be different from the other source/algo''s that were posted, seeing as how the original poster stated he was "just getting different opinions".
But I digress, I''m not trying to start a petty argument here, I''m just trying to explain myself a little further.
Blue*Omega: Assuming that the rectangles will not eventually rotate, my code should work fine... if you plan on rotating your sprites then you should go with something akin to a person''s or SkatMan''s algorithm.
"Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are and what they ought to be."
--William Hazlitt
heh i completely forgot about that one (where would overlap and cross with all vertices outside the rects), since it never occers in my app (mainly because i try to detect the collision before such a case like that happens os it never occered). thanks for pointing that one out 
i guess when i said not close enough type, was about the rects are always tight around the sprite (since whan you rotate the sprite the bound box void starts to increase in size if you keep the bound box axis aligned)
he mentioned collision between rects, which I assumed they could be rotated since rectangles are not always axis aligned. maybe he dont have rects that are not axis aligned, then he could ignore my post and use what void* posted. i was not ryting to show, but show insight on another approach to the problem (he did ask for different opions)
i guess i misread what you where saying, sorry about that void* (well i knew the codey oyu psted was not for the algo, but it seemed you were saying my algo would take axis aligned rects and bound the rotated sprite which it does not)
i agree though, an argugment would be silly, i as well merely clarifing what i posted.
i probally should have examined my algo more beofre posting, since it was written a while ago for a now defunct multiplayer space combat game. lets just say other projects always happen to get in the way of other projects. i really shoudl learn to stick to one project instead of expeirmenting so much and creating many unfinshed apps that for the most part are useless
i guess when i said not close enough type, was about the rects are always tight around the sprite (since whan you rotate the sprite the bound box void starts to increase in size if you keep the bound box axis aligned)he mentioned collision between rects, which I assumed they could be rotated since rectangles are not always axis aligned. maybe he dont have rects that are not axis aligned, then he could ignore my post and use what void* posted. i was not ryting to show, but show insight on another approach to the problem (he did ask for different opions
)i guess i misread what you where saying, sorry about that void* (well i knew the codey oyu psted was not for the algo, but it seemed you were saying my algo would take axis aligned rects and bound the rotated sprite which it does not)
i agree though, an argugment would be silly, i as well merely clarifing what i posted.
i probally should have examined my algo more beofre posting, since it was written a while ago for a now defunct multiplayer space combat game. lets just say other projects always happen to get in the way of other projects. i really shoudl learn to stick to one project instead of expeirmenting so much and creating many unfinshed apps that for the most part are useless
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
