THE PASZ.COM BLOG

Thursday, April 13, 2006

My Desperate Plea

Ok. A bit of a rant this morning.

Why is there no out-of-the-box solution for generating dynamic SWFs on a web server. People, there is a huge need out there! In the past month I've had two potential clients ask me about this capability. People are dying to get customizable audio, images, and video onto the web, and Flash is clearly the killer app for doing this -- if for no other reason than because it's so pervasive. I hope I'm missing something, because it feels like at the moment we're stuck with a bunch of confusing, sloppy-looking solutions.

In the old days, we had Macromedia Generator. I never used it at the time, but it seemed pretty promising. Why was it discontinued without a suitable replacement?

Now Adobe makes Flex. But should I even bother with it when Flex 2 might be coming out any day now, and is sure to be the greatest thing since sliced bread? At least that's what all the hype says. Unfortunately, I find the whole thing somewhat perplexing. Yes, I've spent some time looking at the docs, and yes AS 3.0 sounds cool. But why can't anyone clearly explain what Flex is in one sentence, without lots of buzzwords and diagrams? I just want to build a SWF from XML. Is that too much to ask? Most disheartening at all, I read in Macromedia's Flex book that SWFs generated from Flex won't work unless they're running on a Flex server.

Then we have SWF Scout, which has a really nice feature set (if you're running .Net). But... what's up with their site? Why are there no Testimonials, Discussion Boards or even an About the Company page? Why does their site give me the impression that no one is actually using their product??? I can't convince a client may know next to nothing about Flash to invest in an unproven technology like this.

The same goes for the Open Souce solutions floating around. They don't seem ready for Prime Time. I don't mean to be too hard on people who've accomplished a lot with limited resources. But we need a rallying cry. So here goes...

Come on people! There's serious money to be made by whoever can solve this need in a clean, affordable way. I see no reason why we don't have custom, re-distributable SWFs all over the place. Sent in emails. Viewed on cell phones. Posted on social networking sites. There are millions of potential Flash authors out there. (Not developers. Just regular people.) We just need to give them the right tools to make it happen.

If someone has found a solution that's working for them, please let me know. I'd be thrilled to hear about it.

Monday, April 10, 2006

Flash Dev Gotchas #9 - Don't Over-Engineer the MovieClip

Over the years, Flash developers have tried to follow good OOP principles, and have moved further and further to a point where their code is completely separated from the animations. Putting code in the frames of your animation is a no-no. While separating code makes good sense from an organization and maintainability perspective, when you try to use Classes to control movie clips at the frame level, there can be a performance impact. I learned this the hard way on my last project.

My grand design was to create an Anim class that would be associated with a MovieClip. The class would give me complete control over the animation at the frame level, including to do things like play the movie backwards, or to play it at half speed. My Anim class created an update callback method that updated the animation every frame (it was be called by an onEnterFrame event set up elsewhere):

public function update(){
 var cf = animClip._currentframe;
 if(animClip._currentframe < (animClip._totalframes)){
//play next frame
  actorClip.gotoAndStop(cf + 1);
 }
 else {
//reached last frame. loop back to start of animation
  animClip.gotoAndStop(1);
 }
}

The class worked well in my tests with a simple animation. But the production files that came back from the artists were much more complex, and there was noticeable lag when running the animations from my application (as opposed to running them in a standalone swf).

stop() != play()

I had assumed that I could mimic the play() function by calling a gotoAndStop() on every frame. But what I was really doing was akin to trying to play an analog audio tape on a tape player by constantly pressing and releasing the pause button -- it results in a stuttered playback.

I reworked my Anim class so it just played, instead of stopping and restarting every frame. All of a sudden, the animation played about twice as fast from within my application.

I fell into the trap of trying to over-engineer my MovieClips. There's no need to extend something that already exists and works well. Sure, if I need a particular animation to play backwards, or in slow motion, I might write a class just to handle those particular clips. Or I might even ask the artists to implement these behaviors on the timeline, perhaps even with -- dare I say it -- some code on certain frames of their animation. The latter approach might create a larger SWF, but is more likely to play back at a suitable framerate.

OOP makes it very easy to add new layers of functionality to existing objects. While you may be making your interface more elegant, you might also be creating performance problems. Especially when you're adding the new functionality to something so basic and critical like the MovieClip object. If you do create MovieClip controller classes and other frame-level mechanisms, be sure to unit test them rigorously to make sure you're doing things the most efficient way.