One thing I snuck into yesterday’s code examples without explaining is a way to use different animations for the same property of the same element. The way it works now the functions that generate tween information install commands into the list of animations to perform during each step in the following way, after each element is initialized using bcInitElement function and additional functions for properties not defined therein:
- Assign the state in the beginning initialization, in the bcInitializations[0] array.
- Assign the same state in the animation step before the main series of transformations is to start, if the series of transformations begins after the first animation step. This is added so the element can be returned to its original state when the animation is run in reverse.
- Assign the series of transformations to the desired, contiguous range of animation steps.
- Assign the final transformation in the series to the “ending” initialization, in the bcInitializations[1] array. This is used to “initialize” the state of each element when the simulation is run in reverse.
All well and good, but what if I want to do a series of transformations to an element, even if they involve different properties? Suppose I want to make an element visible by changing its opacity from 0 to 1 from second 1 to second 2.5, then move its left edge from 100px to 401px from second 3.5 to second 5?
Most of it would work fine. The second initialization would start where the first left off, so the initialization for the 3.5-second mark minus one animation step would not be a problem (see step 2, above). The series of transformations themselves, described in step 3, above, also would not be a problem (assuming the animator didn’t try to overlap the transformation series in time, in which case the latter one would always be the last called). The “ending” transform, which is actually the beginning transform when running in reverse from the end, would also not be a problem, because the latter transform would be set after the first one. In that case see step 4, above.
The problem comes from step 1, above. If the second transformation is allowed to initialize the element to the spot where the second transformation ends (which should be where the first transformation begins), then it would override the initial setting of the first transformation series.
Fortunately, there’s a way around that. If you’ll notice in yesterday’s code snippets, the initial state is only assigned to the bcInitializations[0] array if a variable called bcChainFlag is not set. That means that the initialization is inhibited is that flag is set, and this is done by calling the bcSetChainFlag function.
Here are the relevant code snippets.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
//declare, set, and clear the chain flag var bcChainFlag = false; function bcSetChainFlag() { bcChainFlag = true; } function bcClearChainFlag() { bcChainFlag = false; } //example of tween function that inhibits the initialization function bcDefineLeftTween(sElement,pStart,pEnd,tBegin,tDuration,mMethod) { //step 1 here var s = sElement+".style.left='"+Math.round(pStart)+"px';" if (!bcChainFlag) { //only do the first initialization if flag not set bcInitializations[0][0] = bcInitializations[0].push(s); } bcClearChainFlag(); //always ensure the flag is cleared var alpha = Math.round(tBegin * 60.0); var steps = Math.round(tDuration * 60.0); var omega = alpha + steps; var increment = (pEnd - pStart) / steps; var left = pStart; //step 2 here if (alpha > 0) { bcActivitiesList[alpha-1][0] = bcActivitiesList[alpha-1].push(s); } //step(s) 3 here for (var i=alpha; i<=omega; i++) { //> s = sElement+".style.left='"+Math.round(left)+"px';" bcActivitiesList[i][0] = bcActivitiesList[i].push(s); if (mMethod == "linear") { left += increment; } else if (mMethod == "vibrate_right") { var multiplier = i - alpha - (Math.PI*0.5); multiplier *= 0.3; multiplier = Math.cos(multiplier); multiplier *= 100.0; multiplier *= (omega-i) / (omega-alpha); //var multiplier = Math.cos(i - alpha - Math.PI*0.5)* 100 * (omega-i) / (omega-alpha); left = pStart + multiplier; } } //step 4 here bcInitializations[1][0] = bcInitializations[1].push(s); if (omega > bcFinalActivity) { bcFinalActivity = omega; } } //define the handle for the element, //initialize it, //and define the transformations var i22 = document.getElementById("intro22"); bcInitElement(i22,"100px","29px","blue","rgba(0,0,0,0)","99px","0","block","<span style='font-size: 1.8em'>Effect...</span>"); bcDefineOpacityTween("i22",0,1,1.00,1.50,"linear"); bcSetChainFlag(); bcDefineLeftTween("i22",100,401,3.50,1.50,"linear"); |
It should be noted that the sequence above would actually work fine without the bcSetChainFlag() call because the series of initializations makes sense. It is absolutely necessary in the following scenario, however, where the visible parent div is 400px wide.
|
1 2 3 4 5 6 |
var i26 = document.getElementById("intro26"); bcInitElement(i26,"401px","145px","blue","rgba(0,0,0,0)","114px","1","block","<span style='font-size: 1.8em'>Unseen...</span>"); bcDefineLeftTween("i26",401,220,17.70,0.70,"linear"); bcSetChainFlag(); bcDefineLeftTween("i26",220,170,19.40,0.50,"linear"); bcDefineHideTween("i26",25.40); |
In this case a transformation from 17.70 to 18.40 seconds slides the element onto the visible part of the parent div and and a one that bumps it a little more from 19.40 to 19.90 seconds. If the second set of transforms were allowed to govern the initialized state of the element then it would appear in the middle of the parent div at the beginning of a long animation because the initialization for the 19.40 second state would override the initialization for the 17.70 second state.
The Greensock animation package handles this much more smoothly, of course, but this is an intermediate fix I had to put in while I slowly build up the parts of it that I’m actually going to recreate. Each exercise provides more insight into what is needed.
Finally, I use the “bc” prefix on a lot of functions and variables to indicate that all of these items would ideally be placed in a separate JavaScript package which would be referenced and which would have its own namespace. I haven’t bothered doing this with any of the examples I’ve created so for, but I’ve at least established a convention if I ever decide to do so.