Director-like multi-image "sprite" animation

[Ken Ray]

As I've been doing a lot of animating recently (see my announcement about
Stykz), I feel pretty qualified to provide some input:

> 1) If you want to run multiple animations, create your own "frame"
> event. For example, if you want a frame rate of 25fps, set off a
> "frame" event every 40ms. Leave the frame rate as a setting which you
> can adjust. Then on each frame event, update all of your animations at
> once. Picking a reasonable frame rate gives you something to shoot
> for, optimize against and quickly figure out how far you need to go /
> what is realistic.

This is a good basic approach, but the *actual* fps you get is based on how
much actually has to be drawn to the card (at least in my experience). So
what I ended up having to do is to send a message every 125 ms to check how
the frame rate since the last check, and then adjust the "delay" up or down
accordingly. This gives me a close-to-accurate frame rate after about the
first second of animation; I then store the average frame rate across the
entire animation so that the next time it's played (either through looping
or just in the same session), it starts with a more appropriate delay and
you don't get the first second looking a little to fast or slow.
 
> 2) Somewhere around 20-25 FPS should be sufficient for a walk cycle
> although of course it looks better at higher rates. Even 15 fps might
> be enough for drawn animation.

Absolutely! It all depends on the amount of different between the previous
frame and the current frame. This may be why there's 900 frames in the
animation - if each frame is only moving things a few pixels at a time, then
it will look smooth at much lower frame rates.

BTW: On my (admittedly old) MacBook Pro with 2GB, I can't get sustainable
frame rates above 24 fps for the animations I'm doing, but as I mentioned,
the actual FPS is going to be based on how much has to be "drawn" for each
frame.

> 3) Optimize the heck out of your code since Rev isn't well optimized
> for animation out of the box. Squeezing another 1ms out of something
> may actually be a big deal here or at least will stretch the limits of
> what you can do. For example, if a button's location hasn't actually
> changed by a full pixel, don't bother moving it. The extra check might
> be faster than setting the location of things to their current
> location and forcing a visual update. Just a guess / example.

Agreed... I actually went through testing a variety of different methods for
Stykz, and since I'm going with a "one card = one frame" approach (where all
the content for the "frame" is contained in a group called "Stage" on the
card), the fastest animating method I found was opening up a separate empty
predefined "Player" stack window, and then rapidly copying the "Stage" group
to the Player window, deleting it, copying the next one, etc. Believe it or
not, it was faster than any of the other methods I tried (and if you're
interested in them, let me know offlist and I'll send you the results of my
testing).


Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/