Reputation: 116
For quite a while I've been performing rotations simply with:
setOrigin(screenWidth/2, screenHeight/2)
theta = approach(360) // cycles from 0 to 360
cP = vec2(0, 0) // center point
rp = vec2(0, 100) // rotated point
rP.x = cP.x + cos(theta) * 100 //cos accepts degrees
rP.y = cP.y + sin(theta) * 100 //sin accepts degrees
However I've found the following method to be quite widespread
setOrigin(screenWidth/2, screenHeight/2)
theta = approach(360) // cycles from 0 to 360
cP = vec2(0, 0) // center point
rp = vec2(0, 100) // rotated point
rPx = cP.x + (rP.x * cos(theta) - rP.y * sin(theta)) * 100 //cos accepts degrees
rPy = cP.y + (rP.y * sin(theta) + rP.x * cos(theta)) * 100 //sin accepts degrees
rP = {rPx, rPy}
I understand why the second version works mathematically i'm just not sure why on would prefer it over the simpler first method (apart from the obvious case of placing the values within a matrix and performing transformations)
Upvotes: 0
Views: 35
Reputation: 32627
Your first method is a simplified version of the second where you only allow the difference vector (from rotation center to rotation point) to be a horizontal line. If you plug in rp.y
instead of 100
, you will see that you get the formulas of the second variant, where the rp.x
parts are removed.
Btw, the second formulas are not quite correct. The * 100
is wrong because you already multiplied with rp
. In the second line, you have to swap rp.y
and rp.x
to:
rPy = cP.y + (rP.x * sin(theta) + rP.y * cos(theta))
Upvotes: 1