Colission of rotated rectangles.
Ahh!!!! After writing a long post, it just got erased, so I guess I''ll make this one a lot shorter.
My problem is that I am trying to do completely accurate colission detection between two rectangles, each with teh ability to be rotated. I have done basic bounding box colission for non-rotated, but this seems to be a little more complex.
I figured the best way to do this would be to split the rectangles into 4 points, each representing a corner. If a rectangle collides with another, there will always be one point inside of another (aside for the rare situation when two squares overlap, one rotated 45 degrees more than the other, or such similar positioning). That exception aside, I think this solution will work.
Continuing, once I establish 4 points, I thought of getting each line in the rectangles, calculating the normal, and testing to see if the point lies on the other side of all four lines, indicating that the point is inside of the rectangle, using a modified point/slope formula.
This requires quite a bit of trig, is heavy on the processor, and my guess is there may be an easier way to do it with vectors. I don''t know too much about them, so if so, I will definitely need a little insight, or perhaps direction to where I can learn about them.
Thanks for all taking the time for this, and double thanks for anyone responding with some direction.
--Vic--
The future of 2D game development:
Flat Red Ball
this is in 2D right if it is why dont you just see if the lines from point to point intersect, if they do then you have a collison. This would eliminate the 45 problem and, overlap. And it would require no trig.
Maybe i misunderstood but it seems not to hard to me
Maybe i misunderstood but it seems not to hard to me
I actually am going to implement a segment intersection method, but I plan it will be temporary. The reason being that my colission functions have 2 versions. One that simply returns a bool. The other method specifically keeps one sprite dominant and one inferior, and the inferior one will move to the outside of the dominant one if there is a colission. This makes things like creating RPGs with collidable levels a cinch.
For this type of movement, my understanding is that I will have to do points, so that I can move the inferior sprite outside of the dominant one.
--Vic--
For this type of movement, my understanding is that I will have to do points, so that I can move the inferior sprite outside of the dominant one.
--Vic--
alright, i assume that your going to have some sort of priority system for the sprite collisions. If you only had dominate and inferior labels, then what would happen when two of the same type collided? And for movement away, i always just reversed the direction of the sprite and moved it out by a certain number (the speed). This has always worked and i bet you could modify it to move the inferior one.
The dominant and inferior are determined at function call time. For example, say I have a regular Final Fantasy town. The character will always be inferior - it cannot walk through buildings, it cannot walk through characters, it cannot walk through rivers.
Then I loop through the NPCs, making them inferior to all objects. So if an NPC tries to walk into a building, it will stop. If it tries to walk into another NPC, it will stop. If it tries to walk through your charcter, it will stop.
The moving-back method is not a good solution for four reasons:
1. You won't touch the object that you should be able to walk up to and touch. Say my character moves at 5 units per frame (Hehe, I know, assume units are tiny). If he is 4 units away from the wall, and I attempt to walk into the wall, he will move "into" the wall, then moved back outside to his original position of 4 units away from the wall.
2. You will have problems with objects that move at varying speeds. Continuing the example before, if I have a character who is controlled by an analog stick, and I hold the stick all the way so he moves 5 units per frame (assuming constant frame time) he may stop 4.99 units away from a wall. As I lessen the joystick, his speed will decline, and he will "jitter" closer to the wall, until he finall touches it when he is near stopped.
3. This type of colission is burdensome. You must keep track of velocity, which is a pain. More sophistocated colission shouldn't be done as this, as speed only matters if you are doing soft or bouncy surfaces. With dead stops upon colisison, you want it to be exact, and not have to worry about additional members.
4. What if the dominant object is moving? Obviously, the inferior (character) should be pushed or moved out of the way. But if the character is stadning still, there is no velocity to move the character by. Moving the character by the object's velocity will create a invisible barrier of air. If both objects are moving, then you get even worse results.
Hehe, I guess I kinda went off on that. There are quite a few reasons why this doesn't work. Trust me, I did it before and found much better methods, at least for simple colission
However, it appears the solution to my problem truly lies in using vectors, which surprisingly I know almost nothing about. Wonder why they didn't go into much detail on them in my Trig/Calc classes. Well, I now know what I have to read over the next week.
--Vic--
The future of 2D game development:
Flat Red Ball
Edit: Oh, Ha, 5 reasons
5: If you are walking against a vertical or horizontal wall, but are walking diagonal, we generally expect characters to slide along the wall. Moving the character right back to where he was will stop the character. Sure, you could just change one of the units, keeping the other one changing, so the character still slides, but what do you do when you have surfaces that aren't exactly horizontal or vertical. Then you have to do some more complex calculations, which just brings you closer to a solution for my problem.
[edited by - Roof Top Pew Wee on April 13, 2004 9:59:53 AM]
Then I loop through the NPCs, making them inferior to all objects. So if an NPC tries to walk into a building, it will stop. If it tries to walk into another NPC, it will stop. If it tries to walk through your charcter, it will stop.
The moving-back method is not a good solution for four reasons:
1. You won't touch the object that you should be able to walk up to and touch. Say my character moves at 5 units per frame (Hehe, I know, assume units are tiny). If he is 4 units away from the wall, and I attempt to walk into the wall, he will move "into" the wall, then moved back outside to his original position of 4 units away from the wall.
2. You will have problems with objects that move at varying speeds. Continuing the example before, if I have a character who is controlled by an analog stick, and I hold the stick all the way so he moves 5 units per frame (assuming constant frame time) he may stop 4.99 units away from a wall. As I lessen the joystick, his speed will decline, and he will "jitter" closer to the wall, until he finall touches it when he is near stopped.
3. This type of colission is burdensome. You must keep track of velocity, which is a pain. More sophistocated colission shouldn't be done as this, as speed only matters if you are doing soft or bouncy surfaces. With dead stops upon colisison, you want it to be exact, and not have to worry about additional members.
4. What if the dominant object is moving? Obviously, the inferior (character) should be pushed or moved out of the way. But if the character is stadning still, there is no velocity to move the character by. Moving the character by the object's velocity will create a invisible barrier of air. If both objects are moving, then you get even worse results.
Hehe, I guess I kinda went off on that. There are quite a few reasons why this doesn't work. Trust me, I did it before and found much better methods, at least for simple colission
However, it appears the solution to my problem truly lies in using vectors, which surprisingly I know almost nothing about. Wonder why they didn't go into much detail on them in my Trig/Calc classes. Well, I now know what I have to read over the next week.
--Vic--
The future of 2D game development:
Flat Red Ball
Edit: Oh, Ha, 5 reasons
5: If you are walking against a vertical or horizontal wall, but are walking diagonal, we generally expect characters to slide along the wall. Moving the character right back to where he was will stop the character. Sure, you could just change one of the units, keeping the other one changing, so the character still slides, but what do you do when you have surfaces that aren't exactly horizontal or vertical. Then you have to do some more complex calculations, which just brings you closer to a solution for my problem.
[edited by - Roof Top Pew Wee on April 13, 2004 9:59:53 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement