Page 1 of 2
This user is yet to take control of their account and provide a biography. If you are the author of this article, please contact us via support AT actionscript DOT org.View all articles by FlashJunkie
Written by: Flashjunkie
Difficulty Level: Intermediate
Requirements: Flash 4
Download FLA This tutorial will show how to create a Rock-Solid-Will-ALWAYS-Work-Advanced Double-Click based on actual time passing, not based on frame playback in a movie timeline.
What's the difference?
For starters, if you increase the FPS (Frames Per Second - or framerate) of the playback of your movie, your user suddenly has to double-click that much faster for Flash to detect it correctly. Even worse, Flash animations play back at a different rate on different CPU's. Someone on a 486DX has to double-click a lot SLOWER for frame actions to detect the double click than someone on a 500MHz P3. Because the code runs so much slower! How much slower? A piece of code I tested took 20ms to run on a 450MHz P3. It took 580ms to run on a 486DX! Over half a second longer! That means you can never truly guarantee the speed of your double-click detect EVEN IF you always have your Flash animations playback at the same frame rate.
(NOTE: Animations also play back SLOWER when in a web browser window than if they are a standalone ".swf" file.)
A) Create a double-click detect that operates only in one frame.
B) Compensate your code for the variability of CPU speeds.
That's why there are two steps to this tutorial.
Find out just how fast (or slow) the CPU that the Flash animation is running on really is.
Here is Frame 1 of the CPU tester:
Frame 2 says "GoTo Frame 1".
There is a variable on the workspace in Frame 1 called "speed". That's just so you can see the results live. The ".swf" file embedded here shows the results...
When you start up a Flash animation, Flash starts its own timer. The timer keeps counting forever until you stop the animation. You can ask Flash what the value of that timer (in milliseconds) is at any time. You say "GetTimer". So all this code does is:
(A) check the time
(B) count to 1000
(C) check the time again.
The difference between those two times is the number of milliseconds it took your processor (while running Flash) to count to 1000.
I call that difference "CPUlag".
On a 486DX I tried this on, it took 580ms to count to 1000. Over half a second! On a 450MHz P3 it took only 20ms. One fiftieth of a second.
Now that we know how much lag our processor has, we can use that information to slow down the double-click detect to accommodate slower processors. Since on a really fast CPU the lag is going to be less than a fiftieth of a second, we can safely assume we will never need to compensate for faster CPUs. Since the CPUlag on slower processors is exactly proportional to the speed at which that CPU will read the Flash scripts, I simply add the CPUlag to the double-click detect speed.
This variable is called "gap" and it represents the amount of time in between the two clicks.
350 ms seems to be about a comfortable double-click gap (plus CPUlag).
This may seem like a lot of work for nothing but it will be the difference between the double click working for EVERYONE out there on the net or just people with fast CPUs.