So I am working on programming some doors into my game, and the way I want them to function is something like those kitchen doors that have no latch or anything and just loosely allow themselves to be pushed open and close at a leisurely pace. What I have right now is a door class and all the code related to displaying and rotating the door, but I seem to keep flopping on the calculations regarding properly reacting to being collided with (collision detection I have fine, but actual reaction to said collisions is eluding me).

Entities are treated, for the purposes of this collision, as circles. Here's a link to a bunch of diagrams I made in my frustration so that I could look at both cases possible in all 4 quadrants:
http://s957.photobucket.com/albums/ae57/Ph4tM4N/?action=view&current=Doorrotation.jpg
I think that should work for anyone with the link. At any rate, The gist of these diagrams is that the door is the line from p1 to p2, and the intruding entity is the circle of radius r at location c. The door, in order to avoid said intrusion, must change its angle by p in order to avoid the collision. For a while I was just working off of the leftmost graph, but then I realized that in the counterclockwise case, a lot of angles would relate differently to each other. Since I can't really describe this in part without explaining my maths, here it is:

given p1, r, v, c
sin(p+q) = r/p1c
p+q = asin(r/p1c)
q=v-u OR q=u-v (depending on if u > v)
u=atan((cy-p1y)/(cx-p1x))

therefore
p=asin(r/p1c)-q=asin(r/p1c)- either v-u or u-v (not going to retype everything out)
where cx/cy are point c's x/y coords
and p1x/p1y are point p1's x/y coords
and p1c is the distance between point p1 and c.

Which seems to cover all four quadrants moving in both directions as far as I can see. The behavior I'm getting is it only working in quadrant 3 in the clockwise direction. Any other direction and the door is suddenly jumping off at predictable (as in the same) but incorrect angles. Some problems I think might be hurting me are that I am calculating p1c as an absolute distance. Should this be signed in particular quadrants? Am I missing something else entirely? I've gone through several different variations of this same function (some angles can be calculated in slightly different ways) and I've noticed sometimes I get a NaN from a trig function (I'm assuming asin when input is not [-1,1]), which currently just crashes the program.

So, does anyone have some insightful advice to fix this, or, I am reluctant to ask, a way that I can rewrite this all to be easier? (I wouldn't be too enthusiastic about doing that for obvious reasons) If necessary I can post some code bits if anyone wants to take a look, but I'm pretty certain my implementation of the above math is correct.

Thanks,
Ph4tM4N

EDIT: Updated the link to use the same graph uploaded to photobucket, this should work. Also, I have used both atan2 and atan in my code with no luck in this application (though I was already keen to atan2's superiority, I just didn't want to use code and math interchangeably). Though I will say clamping input pre-sin has seemed to eliminate crashes, but I can't be certain it isn't causing problems as far as calculations go until I get something stable working.

[Edited by - Ph4tM4N on December 23, 2010 9:43:38 AM]

I didn't work through the problem, but here's a couple of quick tips:

1. Use atan2() rather than atan().

2. If there's a chance the input to asin() or acos() might drift outside the range of [-1, 1] due to numerical error, clamp the input first, just to be safe.