This topic contains 14 replies, has 5 voices, and was last updated by 
Mark Sibly
1 year, 2 months ago.
-
Posts
-
I was trying to figure out why I couldn’t get a program to work correctly and I couldn’t figure out why. Well it happens to be that rotation on the canvas method works counter clockwise while the trig functions such as sin, Cos, Tan etc.. all work in clockwise direction. Is this intentional or is it bug? I would like to think it’s a bug and would like this fixed if/when possible.
en example:
[/crayon]123456789101112131415161718192021222324252627282930313233343536373839404142[crayon-5cba1439f2aea722941370 inline="true" ]Namespace myapp#Import "<std>"#Import "<mojo>"Using std..Using mojo..Class MyWindow Extends WindowField angle:Float = 0Field stp:Float = Pi/180.0Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=Null )Super.New( title,width,height,flags )EndMethod OnRender( canvas:Canvas ) OverrideApp.RequestRender()canvas.PushMatrix()canvas.Translate(200,200)canvas.Rotate(angle)canvas.DrawLine(0,0,100,0)canvas.PopMatrix()canvas.PushMatrix()canvas.Translate(300,200)canvas.DrawLine(0,0,Cos(angle)*100,Sin(angle)*100)angle+=stpEndEndFunction Main()New AppInstanceNew MyWindowApp.Run()EndBoth lines should be turning clockwise direction I HOPE.
IMHO it is traditional in 2D computer graphics that Y is down not up and hence your trig should read cos,-sin not cos,sin.
is it really traditional?
I never had that issue before. Even Blitzmax does it clockwise.Canvas.Rotate could have been defined as clockwise (inverting y axis in the matrix stuff). But seem a bit late to change it now.
Yea, this makes more sense to me than the traditional…
I just hope I can remember that for later projects.
I am sure others will run in to this problem sooner or later.
So, would that make the Sin function in Monkey2 wrong?
The “angle of rotation” article is not so great in a mathematical point of view (IMHO).
To me,this is the real stuff I think: https://en.wikipedia.org/wiki/Cartesian_coordinate_systemTrigs functions are usually set in a “standard” or “positive” orientation/handedness.
https://en.wikipedia.org/wiki/Cartesian_coordinate_system#Orientation_and_handedness.So, would that make the Sin function in Monkey2 wrong?
If there is something wrong, it is not inverting y axis in the canvas.matrix formulas. The formulas there are the ones for positive coordinate system but a canvas has negative coordinate system.
But on the other hand, it’s ok that AffineMatX uses a positive coordinate system as they are standart Maths concept. Canvas matrix directly uses AffineMat3 and that’s where it hurts.Edit: Canvas is turning counter clockwise so it’s actualy ok!? I’m confused now with all these definitions. ;P
I am trying to get to the bottom of a very insignificant problem that is bothering me and it has to to with the way Monkey2 handles rotation in relation to trig functions and graphics. I would like to see some consistencies thats all. Either way, I have already accepted it. Not that your most recent explanation abakobo made more cense to me.
Hahaha!, I just so your edit. Now it makes cense!
Some more reading (that could make even less sense!) https://en.wikipedia.org/wiki/Rotation_matrix#Non-standard_orientation_of_the_coordinate_system.
In this article a rotation on negative coordinate system should turn clockwise… So there are several opinions!?
True that it would have been easier for this to be consistent.
BUT you can make canvas Extension with a “ConsistentRotate” method ..?
Ok I stop sorry
everything would be so much easier if the computer world would have done everything in standard scholastic trig methods to start with but we are here so OK.
I found a third way of inverting the Y axis. However visually it would not make sense because it will turn graphics upside down. But if you take this concept and perform the transformations using Matrix object the calculations will be applied only to values.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051#Import "<std>"#Import "<mojo>"Using std..Using mojo..Class MyWindow Extends WindowField angle:Double = 0Field stp:Double = Pi/180.0Method New()Super.New("",800,600)EndMethod OnRender(canvas:Canvas) OverrideApp.RequestRender()canvas.PushMatrix()canvas.Translate(200,200)canvas.DrawText(angle + "", 0, 0)canvas.Rotate(angle)canvas.DrawLine(0,0,100,0)canvas.PopMatrix()canvas.PushMatrix()canvas.Translate(500,200)canvas.DrawText(angle + "", 0, 0)canvas.DrawLine(0,0,Cos(angle)*100, -Sin(angle)*100)canvas.PopMatrix()canvas.PushMatrix()canvas.Translate(250,400)canvas.DrawText(angle + "", 0, 0)canvas.Scale(1, -1)canvas.DrawLine(0,0,Cos(angle)*100, Sin(angle)*100)canvas.PopMatrix()angle+=stpIf angle > TwoPiangle-=TwoPiEndEndEndFunction Main()New AppInstanceNew MyWindowApp.Run()EndI think the problem here is that I use the ‘standard’ 2d rotation matrix…
https://en.wikipedia.org/wiki/Rotation_matrix
…but I guess this assumes +y is ‘up’ (and I never really thought about this before) so perhaps the cosines or something need to be negated or perhaps you need to use: scale( 1,-1 ) * rotate( r ) * scale( 1,-1 )?
If this is the case, it wouldn’t be hard to add a canvas ‘mode’ that addressed this if enough people wanted it.
Consistency over all the “rotation” angles would be cool if doable without breaking previous angles things!
I had a quick look at bmx (welll, glanced at digesteroids src), and rotation seems to be the same there, ie: +rotation=ccw. And I think, in the context of a +y=down coord system this is actually correct, these are just numbers after all.
What people are possibly really after here is a way to change +y=down to +y=up? This is probably doable and I think would be quite cool – cooler than just fudging rotation or something.
You must be logged in to reply to this topic.