Speed controlled single frame animations

April 2, 1998
by Steve Kury

Welcome to my second article on object-oriented programming with Lingo. This will discuss a technique for controlling the speed of a single-frame animation, for countering the varying processor speeds across different platforms. It will then be combined with the netMan object, from my previous article, to create a simple multithreaded Shockwave application.

In the past I have found that when my Shockwaves were run on different machines and platforms, the speed at which they operated varied. This is most noticable with animations. Some operated much slower on Macs with slower processors and exceptionally faster on fast PC's. (This can be blazing!) Obviously it is quite difficult to bring an animation's performance on a slower machine up to the level specified on the faster design machine, but it is within the OOP programmers' power to ensure that the animation does not run faster on a machine faster than the design computer.

If an application's tempo is set at 120 frames per second, its performance at that rate is dependent on the machine and processor. (Some processors are not fast enough to accomodate that rate. Beyond that, the amount of onscreen animation activity will determine if it operates at that rate or slows down even more.)

A solution to this is to base the animation speed on the system clock. By setting a time increment that must be passed before the next animation movement, rather than the next frame cycle, variations in frame rate can be negated. Everytime the animation thread is cycled through it compares the time that must be elapsed, in ticks, against the ticks of the system clock and advances the animation only if the allotted time has transpired. When that happens the thread also sets the next time, in ticks, that must be elapsed before the next animation.

This is demonstrated in the accompanying Shockwaves, a miniature theatre marquee and its control box. The control box is implemented so that you can simulate the hypothetical distant server with a constantly changing text file, see "Internet Operations Management, a Threaded Lingo Object." The control box allows you to change the speed and title manually or let it be done automatically. The speed increments for the accompanying example are slow=50 ticks, medium=30 ticks, fast=10 ticks.

This animMan object is combined with the netMan to show the importance of multithreading the marquee. Because the marquee is always cycling through the netMan and animMan threads, the changes are enacted as they are received. If the animation was operating in its own loop, excluding the functions of netMan, it would not be able to respond on the fly to the input from the control Shockwave. The frame script must cycle through both threads so that they can operate "simultaneously."

I won't recapitulate the points made in "Internet Operations Management..." Please note the following:

1. The netMan object utilizes getPref instead of getNetText. Other than that it operates identically to the original version. Notice that getPref call is not asynchronous and getNetText is.

2. The mouseDown loop button interrupts the threading process so that nothing functions outside of it. This is to demonstrate the importance of avoiding such loops. Play with the button to see this happen, and avoid using "mouseDown" and "repeat While" loops.

a. If I put the animation thread into this loop, effectively much smaller than the system/frame loop, the animation won't run faster because it is still controlled by the system clock. If the speed control is removed from the thread so that the animation advances with each repetition of the frame or loop, it will move exceptionally faster as the loop gets smaller.
b. The netman functionality could be called from within this loop, but the point is to only have to implement it once, in an organized manner.

3. The manageNetOps thread calls the animMan's updateSpeed method whenever new information is received from the prefs file, or the hypothetical server-based text file. This is basic inter-object communication.

Play with this demo, examine and absorb the code, and until next time. . .

----- - - - - - ----- - - - - - ----- - - - - - --
- - - - -  AnimMan object class script  - - - - -
----- - - - - - ----- - - - - - ----- - - - - - --

-- animMan demo, created for "Speed Controlled
-- Single-Frame Animation.....Countering Processor
-- Speed Variations."
-- by Steven H. Kury for the 
-- Director Online User Group
-- February 1998

property mySprite, slowInc, medInc, fastInc
property curInc, animTime, baseArt, curArt

on new me, theSprite, startMem
  set mySprite = theSprite
  -- the object's sprite channel
  set slowInc = 50
  -- the possible speed increments
  set medInc = 30
  set fastInc = 10
  set curInc = medInc
  -- the current speed increment
  set baseArt = startMem
  -- the member number of the 
  -- first animation graphic
  set curArt = baseArt     
  - the current animation graphic, always
  -- referenced from the baseArt
  set animTime = the ticks + curInc
  -- the next time the animation
  -- graphic will change
  return me
end

on animThread me
  if the ticks >= animTime then
  -- only animate if enough time has elapsed
    set curArt = curArt + 1
        -- advance the animation graphic memberNum
    if curArt > baseArt + 3 then set curArt = baseArt
        -- reset the animation graphic
    -- memberNum if necessary
    set the member of sprite mySprite = curArt
        -- advance the actual graphic
    set animTime = the ticks + curInc
        -- set the next animation time
  end if
end

on updateSpeed me, speedIndex
  case speedIndex of
  -- update the curInc according 
  -- to the argument read in
    1: set curInc = slowInc
        -- from the Shockwave Prefs
    2: set curInc = medInc
    3: set curInc = fastInc
  end case
end

Sample movies are available in SIT or ZIP format

Steven Kury is an interactive media developer living in the SF Bay area. He has worked on several integrated CD-ROM/internet/backend systems and has good breadth of experience in interactive media, including a stint as a QA engineer on the Director engineering team at Macromedia. He can be contacted at skury@primenet.com.