Archive for the ‘ Flash ’ Category
This looks like a pretty interesting alternative method to get Flash on the iPhone and iPad. From what I have read it sounds like it's slower that regular Flash especially when it comes to interactive stuff like games. At this point it's probably good for ads.
Smokescreen seems to take an SWF and convert into an SVG file and ad some javascript, so the end results are compatible with iPhone and and iPad.
Thanks to Karaminder for pointing me to this.
I just started trying to document all of the classes I have created in my library. This is not complete yet. But many classes have been documented.
I used VisDoc to create the HTML class files. This is a great tool and very convenient to use.
Here's a link: http://www.webdevils.com/docs/html/
Get rid of loaded assets when you're done with them.
http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/display/Loader.html#unloadAndStop%28%29
Note: This requires Flash Player 10.
SWF files loaded into Flash can sometimes still exist after they have been removed from the stage. The is cause by teh way Flash cleans up elements. If an element is referenced by another object Flash figures it's still in use and should no be removed.
In some cases this can work to your advantage. Imagine you have a dialog box that appears on the stage periodically to set options in your application. You can remove it from the display list, and then add it to the display list at a later time and have it in tact with all of it's elements in the same state.
In other cases this can be a problem. For example you load an swf and then you remove it from the stage, but it still takes up RAM and might even still be running it's enter frame or other events in the background.In this case it's hurting the efficiency of your application.
The unloadAndStop() method tries to solve this by stopping all actions running in a loaded element and clearing the element out of RAM. The unloadAndStop() methos belongs to the Loader class. The idea is to call this method on your Loader instance to clean what you have loaded.
I posted a bunch of video tutorials here: http://www.screencast.com/users/webdevils# . This is a new site with more tutorials. The last site I used was Vimeo. Their site tended to resize the videos and put more restrictions on uploads. The new site doesn't resize or recompress the videos so the quality us much better. They also support flv, which allowed me to upload some tutorials I had in this format.
These tutorials cover various aspects of Flash from beginning to more complex stuff.
I'm going to upload the example fla files to the google code site as soon as I get a chance.
When working with MouseEvents the event object provides two properties that refer to object that originated the event: target and currentTarget. The right choice between these two is almost always currentTarget.
The problem with target is that often it is not the object that you think it is. The target property is the object that was actually clicked. This can any object nested within the MovieClip that was clicked, and often not the MovieClip itself, which is what you are most often expecting.
The currentTarget property on the other hand is the object that registered the event. Which is almost always what you are expecting.
So for general use it should always be currentTarget. The target property does provide an interesting function but in most cases it's not what you think it is.
Here's a great article on making a Jpeg file from a movieclip with AS3.
http://henryjones.us/articles/using-the-as3-jpeg-encoder
Here's a list and quick review of each of the popular Flash physics engines.
http://henryjones.us/articles/actionscript-3-physics-engines
Yet another one! This looks like another good physics engine for Flash.
http://box2dflash.sourceforge.net/
Here's a few video tutorials on using Box2d. These look pretty interesting. There are a lot I watched a few and got some good information.
And another, physics engine. this one looks pretty good.
http://blog.generalrelativity.org/actionscript-30/foam-rigid-body-physics-engine-alpha-release-01/
After playing with FOAM for an evening, I found this engine to be a fairly easy to work with. I did run into a problem where the FOAM Vector class conflicted with the built in Flash Vector class. The Flash Vector class was added in CS4, FOAM obviously was written before this.
The problem could have been circumvented by carefully qualifying package names. This would have been an elegant and intelligent solution. In stead I decided for the more ham fisted approach of changing all instances of the name Vector to VectorPoint.
I just opened all of the files in the org.generalrelativity.foam and subpackages and did a find and replace on each file, replacing Vector for VectorPoint. Don't forget to change the file name of Vector.as to VectorPoint.as. Compiler errors will often point out any spots where you missed an instance of the name.
The generalrelativity blog posts some FOAM renderers. This are useful files. I packaged them in the org.generalrealtivity.foam.view package. It seemed like a logical place to store them. Don't forget to change the package declaration at the top of each of these files.
FOAM seems pretty easy to use. Unlike Box2d it uses pixels and stage coordinates to position elements on the stage which made it more intuitive to use. The property names seem very intuitive also. Moving objects look to all be built off the SimpleParticle class. Which has obvious properties like x and y to work with. So, creating any Object that inherits from SimpleParticle, you can position it by setting it's x and y to stage coordinates. Pretty simple. Almost like working with regular MovieClips.
I did notice that fast moving objects could pass through another object. I assume this is caused when the velocity is great enough that the object moves past the interposing object without intersecting.