Flash builder containers with SWF files…

Development Update, Greg Pardo 1 Comment

Greg Pardo | January 27, 2012

Here at RETRO Lab we like to get things done right the first time. This post is for any programmers out there who struggle with flash containers.

First let me begin by saying that as a developer, you don’t always know how the client will be using what you’ve made. Many times we have to make decisions about whether to take a quick-and-dirty approach or build a more dynamic application that can be altered easily in the future. In these situations it’s important to probe the client for as much information as possible. However, in this case, the client was developing at the same time so it was pretty hard to make final decisions early on without knowing how our games would be implemented by our client. As it turns out, they wanted to integrate them into a interactive program they had been building in Flash Builder.

Some of the issues we encountered along with the solutions we came up with:

  1. A resolution change: We developed five or so games at a resolution that ultimately ended up changing. Since many of the games we coded for a static resolution, parts of the games needed to be reprogrammed. Any variable or constant that had importance relative to the dimensions of the product needed to be updated. Another issue is scaling without pixel distortion. When you shrink a stage of a non-vector based game in a SWF, you’re going to have some ugly issues and frame-rate changes. In our case our client was willing to accept this and I found a way to enable bitmap smoothing on every bitmap in a flash file which also helped.

  2. Masking: When you’re running a SWF game alone or in an html container, it’s going to perform differently than if it was in another flash container. I personally always apply a mask to the stage that is the size of my clip. That way, nothing outside the area I want gets displayed. Seems simple enough but when you have a Flash Builder or SWF parent of your game, the stage is much bigger your game is added to the stage they have versus creating a new stage. The end result is masking the parent’s content and a whole bunch of other issues I won’t get into. So how did we solve this. It was kind of a pain but instead of adding everything to the stage, you should create a MovieClip the size you want, add that to the stage, and then add all your game assets onto that. That way you can create a mask specifically for this clip and avoid any direct stage manipulation. Which brings me to the third issue.

  3. Stage Properties: Manipulating the stage is fine if you are running your app/game from an html or projector like I mentioned above. When you start messing with the stages settings in a parent flash-based container, you will overwrite that containers stage settings. This will obviously lead to the container application no longer performing how it once did. So avoid setting any of the stage properties and try to keep it all local.

So overall this project was an experience and it’s a testament to how nasty flash can get when you start embedding SWF files within each other. Hopefully the problems we solved will put more pressure on our team to take these issues into consideration before we go and take a traditional approach to AS3 programming. Good luck!

One Response to “Flash builder containers with SWF files…”

  1. Into the abyss: A retrospective analysis of working with clients using Flash Builder containers « Greg Pardo's Digital Portfolio says:

    […] Flash builder containers with SWF files… Filed under: Uncategorized Leave a comment Comments (0) Trackbacks (0) ( subscribe to comments on this post ) […]

Leave a Reply


2 − = one