Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Michael71

Element rotation interferes with element position animation (element goes up instead of down)

Recommended Posts

Hello,

 

I have the following code:

 

$(document).live('keydown',function(event){
 var key = event.keyCode;
 if(key==39){
  TweenMax.to($("#hero"),0.1,{css:{'left':$("#hero").position().left+40}});
 }
 else if(key==37){
  TweenMax.to($("#hero"),0.1,{css:{'left':$("#hero").position().left-40}});
 }
 else if(key==38){
  TweenMax.to($("#hero"),0.3,{css:{'rotation':-30}});
  TweenMax.to($("#hero"),0.1,{css:{'top':$("#hero").position().top-10}});
  TweenMax.to($("#hero"),0.6,{css:{'rotation':0}});
 }
 else if(key==40){

  TweenMax.to($("#hero"),0.1,{css:{'top':$("#hero").position().top+10,'rotation':30},onComplete:function(){
   TweenMax.to($("#hero"),0.1,{css:{'rotation':0}});

  }});
 }
});

 

What this does is to read the "arrow" keys from the keyboard and move the element (hero) up/down/left/right

 

However when pressing the down button continually, the element goes up instead of down, it does not do that when there is no rotation however.

For some reason rotating the object gives it wrong .position().top value.

It used to mess up moving upwards too, but I solved it by resetting the rotation to 0 after the animation (still its a workaround though).

 

Anyone knows why is this happening? Or how it could be solved/worked around?

 

You can view this here: http://www.netgfx.com/trunk/scrollingBG/

 

Thanks in advance.

Link to comment
Share on other sites

First of all, thanks for the sample code.

 

It looks like that's just a problem with the way jQuery reports position(), like it takes into account the rotational value and draws a box around that and then reports the top position based on that box, so it isn't an accurate representation of the "top" property of the element itself.

 

For example, imagine a 100x50 box that's located all the way at the top left corner of the window. Of course the css "top" and "left" properties are 0px. If you rotate it 90 degrees, that wouldn't change the "top" and "left" properties at all, but if you drew a box around the element in its new rotated state, its top left corner would APPEAR to be at 25px, -25px (assuming it rotated around its center). See what I mean? THAT seems to be what jQuery reports and I don't think it's what you actually want.

 

So ultimately it's a logic flaw in your code.

 

In the example above, after the element was rotated and you create a tween from position().top + 10 which would be -25 + 10 (-15). But the "top" style property is currently 0, so you'd be animating it to -15, causing it to go UP! But obviously you meant for it to take the current "top" property (0) and add 10 to it.

 

Does that make sense?

 

I suspect that maybe you should simply use a relative tween like top:"+=10" which would not only make it more accurate, but your code would be much more concise too :)

Link to comment
Share on other sites

I figured that the JQuery position report was giving me (not what I expected), and therefore I rotated the actual image and not the parent div, and I only increased/decreased the top of the parent. This however might (I have not seen any decrease in performance) lead to more computing, so I will try the relative tween value as you suggested.

 

Thanks for the help...again.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×