Oh, I suppose I should comment on what went wrong with your code in case you wanted to know why it wasn't working. You were sort of close at least.
First of all, the dot product of two unit length vectors is equal to the cosine of the angle between them. So you can get the angle using acos(dot(v1, v2)), but it will always give you a value between 0 and pi radians (0 and 180 degrees). Not really what you want in this case. Also, you were comparing the angle of the vector that pointed from the origin to the center of the circle, and the vector from the origin to the mouse point. Also not really what you wanted.
If you wanted to do it using trig functions you can use atan2(). atan() converts a slope (y/x) into an angle, again between 0 and pi. With atan2() you pass it both the x and the y and it gives you the full angle (0 to 2*pi). It also doesn't break down when you try to get the angle of a vertical direction which would have an infinite slope. Using atan2() you could have done something like this:
Code: Select all
float angle = atan2(mouseY - centerY, mouseX - centerY);
float pointX = cos(angle)*radius;
float pointY = sin(angle)*radius;
While this works, it's usually best to avoid trig functions when possible. The biggest reason is that you often run into issues with ranges. An example from your code above:
Code: Select all
acos(cpvdot(cpvnormalize(v1), cpvnormalize(v2)));
Somewhat surprisingly, this can break catastrophically if v1 equals v2. The problem is that acos() only works on values strictly between 0 and 1. Because you are working with floating point numbers cpvnormalize() is going to return a vector with a length that is very close to 1 (like 0.999999999 or 1.000000001), but rarely exactly 1.0. This means that the result of cpvdot() might be > 1.0 and acos will break. The correct thing to do is to take the minimum of the dot product and 1.0.
Code: Select all
float dot = cpvdot(cpvnormalize(v1), cpvnormalize(v2));
acos(cpfmin(dot, 1.0))
I've ran into this issue before and it took a long time to find the problem. :-\ Another reason to avoid trig functions is that they are sloooooooooooow, really really slow. Don't avoid them simply because they are slow, but don't build an algorithm around performing tens of thousands of sines and cosines every frame.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/