Game Development Reference

In-Depth Information

On the second frame, the ]__ahan]pekjT initial value of 0.2 is added to the object's current t position,

resulting in a new t value of .31*.. Because the right arrow key is still being held down, this code is

then run:

ahoaeb$arajp*gau?k`a99Gau^k]n`*NECDP%

w

[]__ahan]pekjT9,*.7

y

It adds an
additional
0.2 to the [rt value, giving it a new value of ,*0. (You can see this new value

reflected in the third trace.) 0.4 is then added to the object's t position, resulting in a new position

of .31*11.

Strange! 275.55 doesn't equal 272.2 plus 0.4, so logically the new value should be 275.6. But why is

it 0.05 less? This again has to do with the way binary systems deal with fractional numbers. Behind

the scenes, the CPU actually represents 272.2 plus 0.4 as 275.59999999999997. Almost 275.6, but not

quite. Flash therefore decides to round this down to the nearest multiple of 0.05, which is 275.55. It's

not completely accurate, but remember that I'm talking about 1/20 of a pixel here! The difference is

so small that it's absolutely imperceptible when the object moves across the stage.

You can see from this trace that the []__ahan]pekjT value continues to compound by adding 0.2 to

its value each frame until it finally reaches 5, and the object is clipping along at quite a quick pace. All

this adds up to a very neat illusion that the object is accelerating.

The last thing that the code does is stop the object, which is handled by the kjGauQl event handler:

lner]pabqj_pekjkjGauQl$arajp6Gau^k]n`Arajp%6rke`

w

eb$arajp*gau?k`a99Gau^k]n`*HABPxx
±

arajp*gau?k`a99Gau^k]n`*NECDP%

w

[]__ahan]pekjT9,7

[rt9,7

y

ahoaeb$arajp*gau?k`a99Gau^k]n`*@KSJxx
±

arajp*gau?k`a99Gau^k]n`*QL%

w

[]__ahan]pekjU9,7

[ru9,7

y

y

This sets the object's acceleration and velocity to zero when the appropriate keys are released.