Vergroot/Enlarge

Page tearing is the effect you get when the upper part of the screen is updated, while the lower part of the screen is still showing the previous frame. The effect was very clear with the light arrows on a dark background. Especially the sloped sides of the arrows would show the page tearing. The jerky motion was worse in Flash than in Director, especially with the photos.

So we had 3 factors showing page tear: sloped sides, high contrast and slow animation. The slow animation would also show choppy motion. This wasn't all that bad on a regular computer screen, but 20 times enlarged it was clearly visible. Not from the back of the hall, but as it goes in life, the most important people (the ones that pay you) sit in the front row.

I had been playing with the PTK game engine some time ago and I decided to give it a try. The PTK game engine is a C++ framework for creating 2D games. It is multiplatform (windows, mac), it is cheap and it is surprisingly easy to use. I am not a C++ master at all, I just know about OO programming and I know what pointers are, and that's about it. I never used any of the more advanced C++ features such as templates or STL or interfaces or COM. But that's enough to work with PTK.

You can tell PTK to synchronize the framerate with your screen's vertical refresh rate. Since PTK uses OpenGL or DirectX internally, it can go a lot higher, I got a framerate of 400 fps on a G5 Mac, but it doesn't make sense to render more frames than your screen can display. The double buffering eliminates page tearing completely.
Not necessary but very useful in this case is that PTK is multiplatform, because our motion designer works on a Mac and I worked on a PC, since the final result had to run on a PC. The code I wrote was almost completely portable. I used XCode 1.5 on Mac and Visual C++ 2003 on Windows. Just for importing headers and some path stuff, I used #if defined(__APPLE__) .

I didn't feel like programming all the animations, so I used the tinyXML library to parse an XML file, which would describe the animation. While I was having fun playing with something new our motion designer had the worst time of his career. He had to create animations like this:

<?xml version="1.0"  standalone="no" ?>
<config debug="true" fullscreen="true" width="1600" height="1200">
<scene type="sequence">
        <sprite path="assets\long_bigblue.png" startx="-2785" endx="right" starty="350" endy="" speed="40" loop="true" />
        <sprite path="assets\long_bigblack.png" startx="-1600" endx="right" starty="center" endy="" speed="90" loop="true" />
        <sequence>
                <sprite path="assets\partnering_state.png" startx="-2000" endx="right" starty="200" endy="" speed="130" loop="false" />
                <sprite path="assets\partnering_state_txt.png" startx="3000" endx="left" starty="300" endy="" speed="-156" loop="false" />
        </sequence>
</scene>

This way we got a perfectly smooth animation. The only thing with PTK as compared to flash is that you have to code lots of stuff yourself. To give you an example, when I tried to load all the graphics at the start of the application, it wouldn't fit into the video RAM, so it would use system RAM, which would slow down the animation to 10 fps. I had to rewrite part of the application and load graphics per scene. This is something that Flash handles by itself.
Anyway I wrote 1612 lines of code. In Flash one tenth would have been sufficient I think. But again, no jerks and no page tearing.

Since we had this great hardware setup standing there for a couple of days, the scientist in me had to do some experiments. I created a number of Flash movies and tried them out in between rehearsals of the show:

• a 30 fps frame based animation. This was jerky.
• a 120 fps frame based animation. This was the least jerky of all movies. The only problem was that it couldn't keep up with the target frame rate once there were 5 or 6 graphics on the stage. The actual frame rate would drop to 40 something. (Keep in mind that some of these graphics were 3000 x 500 pixels) So the animation would clearly slow down.
  
• a 30 fps time based animation. This was the most jerky of all. Flash would suffer from hick ups every so often. Since the animation was time based a sprite that would go 60 pixels / second would jump 15 pixels instead of 2 pixels when Flash hangs for a quarter of a second. This is 5.8 cm on the projection screen instead of  0.8 cm.
• a 60 fps time based animation, same as the 30 fps version.
• a 120 fps time based animation, same as the 30 fps version. With the same I mean that the 60fps and the 120fps animation was going smoother than the 30 fps version, but once Flash would hang for fraction of a second the result is the same.
  

I was actually very surprised to see that the time based animation appeared more jerky than the frame based solution. This proves once again that testing is better than assuming.