Home Tutorials Forums Articles Blogs Movies Library Employment Press
Old 03-10-2004, 11:07 PM   #11
thaumaturgy
Macromedia Mercenary
 
thaumaturgy's Avatar
 
Join Date: Feb 2004
Location: Rose Bowl Country
Posts: 300
Send a message via Yahoo to thaumaturgy
Default

Did you ever know that you're my heeeerrroooooooo....

Seriously, that's just some next level isht. Now if I could only apply it to my projects...
thaumaturgy is offline   Reply With Quote
Old 03-11-2004, 01:55 AM   #12
thaumaturgy
Macromedia Mercenary
 
thaumaturgy's Avatar
 
Join Date: Feb 2004
Location: Rose Bowl Country
Posts: 300
Send a message via Yahoo to thaumaturgy
Default

Oh, question:

What do the values "r" "p" and "f" stand for in your equations?

r = ratio
p = power (exponential?)
f = function?

Also: How does the value of "f" affect the final easing output?
thaumaturgy is offline   Reply With Quote
Old 03-11-2004, 02:38 AM   #13
pixelwit
village halfwit
 
pixelwit's Avatar
 
Join Date: Jul 2001
Location: USA, PA
Posts: 3,330
Default

Yes, R, P, and F stand for Ratio, Power and Function. Sometimes Power is exponential, sometimes it isn't, it depends what easing equation (ezSine, ezExpo... etc.) you're using.

The easing equations are generally just ways of describing a curve. In one of the examples I previously provided I traced out the results for values between zero and one in .1 increments. the results could easily be plotted on a 10 by 10 grid. Imagine the input value (a .1 increment) as your step in the X direction and the returned value as a step in the Y direction. It might look something like this in ActionScript:
PHP Code:
lineStyle(0);
gridSize 400;
steps 100;
for(var 
i=0i<=stepsi++){
    var 
i*(gridSize/steps);// constant rate
    
var Math.easeIn(i/steps)*gridSize// eased rate
    
lineTo(xy);

Which easing function you use determines the curvature of the line.

Hope it helps,

-PiXELWiT
http://www.pixelwit.com
__________________
There are no answers, only choices.
pixelwit is offline   Reply With Quote
Old 03-11-2004, 04:09 AM   #14
thaumaturgy
Macromedia Mercenary
 
thaumaturgy's Avatar
 
Join Date: Feb 2004
Location: Rose Bowl Country
Posts: 300
Send a message via Yahoo to thaumaturgy
Default

I see now. Thanks!
thaumaturgy is offline   Reply With Quote
Old 03-11-2004, 03:08 PM   #15
boyzdynasty
Senior Member
 
boyzdynasty's Avatar
 
Join Date: Aug 2002
Location: Philly
Posts: 2,583
Default

i'm trying to test the code...copied and paste...but I get an error "Math.easeIn...." and all the functions not recognize.

What can I do to fix this?
__________________
I need a new signature!
boyzdynasty is offline   Reply With Quote
Old 03-11-2004, 03:13 PM   #16
splict
spend my time in blender
 
splict's Avatar
 
Join Date: Oct 2003
Location: tampa, fl
Posts: 1,138
Default

are you using mx2004? if so, don't forget to change to AS1 in your publish profile.

btw, nice work, pixelwit.
__________________

Certified Flash MX 2004 Developer
splict is offline   Reply With Quote
Old 03-11-2004, 04:46 PM   #17
boyzdynasty
Senior Member
 
boyzdynasty's Avatar
 
Join Date: Aug 2002
Location: Philly
Posts: 2,583
Default

oh

that is really nice.
__________________
I need a new signature!

Last edited by boyzdynasty; 03-11-2004 at 04:49 PM.
boyzdynasty is offline   Reply With Quote
Old 03-11-2004, 06:28 PM   #18
pixelwit
village halfwit
 
pixelwit's Avatar
 
Join Date: Jul 2001
Location: USA, PA
Posts: 3,330
Default

I haven't really gotten into AS2 (waiting for Moock's new book) but I've looked at a few examples of class definitions and here's what I came up with:
PHP Code:
class com.pixelwit.ease{
    static function 
easeIn (r:Numberp:Numberf:function):Number{
        if(
== undefined2;
        if(
== undefined)Math.pow;
        return 
f(rp);
    }
    static function 
easeOut (r:Numberp:Numberf:function):Number{
        return 
1-easeIn(1-rpf);
    }
    static function 
easeInOut (r:Numberp:Numberf:function):Number{
        if(
r<.5)return easeIn(r*2pf)/2;
        return 
.5+easeOut((r-.5)*2pf)/2;
    }
    static function 
ezExpo (r:Numberp:Number):Number{
        if(
r==|| r==1) return r;
        if(
p<2)2;
        return 
Math.pow(p10*(r-1));
    }
    static function 
ezCirc (r:Numberp:Number):Number{
        
= -(Math.sqrt(1-r*r)-1);
        if(
p>1) return easeIn(r, --pezCirc);
        return 
r;
    }
    static function 
ezSine (r:Numberp:Number):Number{
        
1-Math.cos(r*Math.PI/2);
        if(
p>1) return easeIn(r, --pezSine);
        return 
r;
    }

If anyone familiar with AS2 has anything to add or can brief me on how to implement such a class definition in MX04 I'd appreciate it.

-PiXELWiT
http://www.pixelwit.com
__________________
There are no answers, only choices.

Last edited by pixelwit; 03-11-2004 at 06:49 PM.
pixelwit is offline   Reply With Quote
Old 03-12-2004, 02:17 AM   #19
robertpenner
Registered User
 
Join Date: Apr 2001
Location: Vancouver
Posts: 36
Default

Hi Pixelwit, thanks for emailing me about this thread. You're obviously comfortable with the math and it's cool to see the equations massaged into different forms like playdough. There is a nice elegance to your method of replacing a number of different functions with a few multi-capable ones.

Here are some thoughts:

1. Having a consistent function signature--in my case, (t,b,c,d)--is extremely important to me, as it allows the easing methods to be easily swapped like plugins.

2. For optimization, I try to avoid having an easing function call another one, to keep the number of function calls down (since they are slow in ActionScript). You have somewhat of a tree structure to your functions, which is cool in how you generate a lot of possibilities from a little bit of code. I chose to go with a flattened hierarchy for speed and also to keep the same function signature.

3. Ease of use (no pun intended): To you, it doesn't seem more complicated or extra work to do the scaling and shifting math outside the easing function. I think, though, that it makes the learning curve noticably steeper for most people. I'm totally with you on the normalization between 0 and 1. Each of my equations is based on a normalized curve which is then scaled and shifted.

With either your or my approach, the following things have to be done for a tween:

- define the starting value, change in value, and the duration (usually in frames or seconds)
- define the current time (usually in the same units as duration, so frames or seconds)
- normalize the time to be between 0 and 1:
t/d
- feed time into a normalized easing equation:
f(t/d)
- scale the function's result to the size of the tween:
f(t/d)*c
- shift the result to match the starting value of the tween:
f(t/d)*c + b

These steps can be done inside the API or outside. I think that having the mundane tasks of t/d*c+b inside the easing function reduces the risk of typos and mistakes.

With an API like yours that is all normalized functions, that does allow you to do some neat stuff like easily layering functions. But then the end users have to do the normalizing, scaling, and shifting themselves--unless you provide some kind of wrapper, which is essentially what I'm doing, but not with functions calling functions. I like to keep the API close to the terms in which people think. They can understand (t, b, c, d) reasonably well (although I've had plenty of questions about it) because those are the essential properties of a tween. If you'd like to educate people about point redistribution with normalized curves, good luck to you--let me know how it goes!

Thoughts?
robertpenner is offline   Reply With Quote
Old 03-12-2004, 06:23 AM   #20
pixelwit
village halfwit
 
pixelwit's Avatar
 
Join Date: Jul 2001
Location: USA, PA
Posts: 3,330
Default

Holy (string of expletives deleted) cow! Robert Penner talked right to me. Well... sort of. *does the happy dance* Sweet.

Comfortable with math??? Ha tell that to both my Algebra 2 teachers (I liked the class so much I took it 2 years in a row. ).

By the way, in case anyone missed it, he said the functions were "cool", "nice", "elegant" and "multi-capable". And that was just in the first paragraph! Okay, sorry, I just had to point that out.

Thought 1: Signature? Referring to the accepted arguments in a function? That's a new one to me, sounds like a pattern type thing or something? But I digress... Isn't the way I have mine set up consistent? All functions accept R, P, and F in that order. Are my functions less consistent because the last 2 arguments are optional or am I misunderstanding the concept of a signature?

Thought 2: Functions calling functions calling functions. I did some moderate performance testing and found one of my slowest function calls "var x = 5+Math.easeInOut(3/10, 1, Math.ezSine)*10;" takes twice as long to execute at .52ms compared to your equivalent "var x = Math.easeInOutSine(3, 5, 10, 10);" which takes .26ms. Two times slower (or is it half as fast?) isn't good. So it sounds like a pretty good idea to at least rewrite the easeOut and easeInOut functions to not call each other or easeIn while still retaining the F argument to allow a certain level of flexibility. That would also help cut down the amount of times I validate or check to see if the arguments are within an acceptable range.

Thought 3: Ease of use. I probably shouldn't admit this but it took me quite a while to figure out how to use your equations, this probably says more about me than it does your functions so please don't take offense. My greatest stumbling block was the "time" concept and when I finally understood that I had one question. Why do you assume a start time of 0? I mean the way the whole thing works is you sort of have 2 sets of variables side by side. On one hand you have values representing time and on the other you have values representing position (or whatever else you might be easing). Within the position values there's a starting position, a current position and an end position. Within the time values there's a starting time, a current time and an end time. It's the correlation between these sets of values which allow you to determine current position based on current time so why not represent all values from both sides? Wouldn't that increase ease of use or standardization? If nothing else it would make easing with getTimer a lot easier (for whatever that's worth). My guess is that you figured the start time wasn't all that relevant to the actual easing function. Once you take this step though, isn't it just as easy to say the starting position is equally irrelevant? I Hope you you understand what I'm trying to get at here as I'm having a pretty tough time getting the thoughts out of my head and onto the screen.

In my mind it would never occur to me to use a linear tween function to do a linear tween. You know where you're at, you know where you want to go and you know how many frames it'll take to get there so just divide how far you have to go by the amount of frames, add that amount each successive frame and in no time you're there. But when it comes to easing... boy that's a tough one and I really could use a few functions to help me out. So that's what lead me to try to isolate the easing from the actual tweening. Since I thought this way I sort of thought others would do the same, but I'm often wrong when it comes to such assumptions (and I do mean often ).

I really appreciate your taking time to check on this thread and writing such a comprehensive response.

Thanks for your time. I hope to hear more from you in the future.

-PiXELWiT
http://www.pixelwit.com
__________________
There are no answers, only choices.

Last edited by pixelwit; 03-12-2004 at 06:28 AM.
pixelwit is offline   Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump


All times are GMT. The time now is 06:36 PM.

///
Follow actionscriptorg on Twitter

 


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Ad Management plugin by RedTyger
Copyright 2000-2013 ActionScript.org. All Rights Reserved.
Your use of this site is subject to our Privacy Policy and Terms of Use.