Further Flash Development for PSP

So over the long weekend I spent some more time plugging away on the PSP version of my portfolio site. And despite my best efforts I have stumbled on an issue that continues to upset the PSP version of the flash player�s limited memory.

First a little background to the site. The first version of the site was a journey into a completely code generated flash movie. That is to say, every possible aspect would be generated using ActionScript 2. The rational being to learn some more about the Draw API and also get clarify the ideas of OOP and MVC that i had heard so much about all over the web, but had yet to apply to flash properly. That first development has also offered a great focus for development in terms of learning Flash 8 and more recently both Flash 9 or Action Script 3 and now this latest version for the PSP version of the flash player.

So with the exception of the loaded Bitmap Images and the XML obviously, the rest of the production is all code. In addition this whole experiment has given me some great learning experiences in Eclipse, mtasc, and ant and the whole OpenSource Flash Development.

In my previous post on flash development for PSP I highlighted the need to be very careful with the amount of animation and data being thrown around in the flash player and the need to monitor specifically the memory usage. This is something I have been keeping in mind as I built up the code for the PSP version of my development here:

First I have the base BittubeClass that contains the mtasc main entry point and an application level control class. This handles loading XML, Images and also the creation of Interface Classes. Then I have the various interface elements split into four classes, Loader, NavBar, NavItem, and ContentArea.

Between these classes I am also using some of the mx core classes, or versions of them. These include.

mx.events.EventDispatcher;
mx.transitions.Tween;
mx.transitions.easing.Regular;
mx.xpath.XPathAPI; (modified to work in mtasc)
mx.utils.Delegate; (modified to work in mtasc)
MovieClipLoader (based on MovieClipLoader6)

The base output from mtasc of the project is a swf that is about 14k in size. Which I am pretty pleased with. I did wonder if generating all the visual assets being created via code was as efficient as using the flash IDE to create the assets. So with this question in mind I produced the following test code:

[as]//generate and display 4 sqaures
var drawSolidRectangle = function(mc_target:MovieClip, str_clipName:String, int_depth:Number, int_w:Number, int_h:Number, int_fillC:Number, int_lineC:Number, int_lineW:Number):MovieClip
{
var mc_retClip:MovieClip = mc_target.createEmptyMovieClip(str_clipName, int_depth);
if(int_lineW != undefined && int_lineC != undefined)mc_retClip.lineStyle(int_lineW, int_lineC);
mc_retClip.beginFill(int_fillC);
_drwRct(mc_retClip, 0, 0, int_w, int_h);

mc_retClip.endFill();

return mc_retClip;
}
var _drwRct = function(mc_clip:MovieClip, int_x1:Number, int_y1:Number, int_x2:Number, int_y2:Number):Void
{
mc_clip.moveTo (int_x1, int_y1);
mc_clip.lineTo (int_x2, int_y1);
mc_clip.lineTo (int_x2, int_y2);
mc_clip.lineTo (int_x1, int_y2);
mc_clip.lineTo (int_x1, int_y1);
}
drawSolidRectangle(_root, “square0_mc”, 0, 100, 100, 0xff0000);
drawSolidRectangle(_root, “square1_mc”, 1, 100, 100, 0xff0000);
drawSolidRectangle(_root, “square2_mc”, 2, 100, 100, 0xff0000);
drawSolidRectangle(_root, “square3_mc”, 3, 100, 100, 0xff0000);[/as]

This results in a file that is 972Bytes in size.

However by simply having a square symbol in the flash library, and placing it on the stage 4 times, and then providing the same instance names as are used in the code above, the swf output is a file of 183Bytes in size. So a smaller initial file in comparison to the code generated assets.

Both movies were exported as Flash 6, using ActionScript2. All other settings were identical.

Further on from this I monitored the memory usage of both movies in task manager. The code generated movie actually appeared to use slightly less memory than the IDE generated movie (6,964K as opposed to the IDE created movie which used 6,988K). So in this particular test Code generated assets actually made a lower impact in memory usage, something, I confess, suprised me.

Returning to the larger development I don�t know if the findings above scale into a more complex project, I would assume that as the code generation continues there would be a point where it will become more efficient to reuse existing IDE based assets than storing dynamically generated assets in memory. I have yet to find time to run an experiment in this way.

Through testing my existing file on the in the PSP flash player I discovered however that my movie still eventually toppled the memory barrier. The initial load of my movie is quite modest. The SWF is 14K compressed The 2 images I load are about 15K in total. The XML Document for the navigation is 285 bytes, the XML documents for the 3 areas are 81K in total. This all gives a total file space requirement of around 115K rounded up to the nearest 5K. This is well within the memory constraints of the 1.5Mb available on the PSP. Yet eventually after clicking through the movie a few times I see the “Out Of Memory” message.

I have checked the movie on the flash 8 player on my windows box. The initial Load of the movie reports 8,576K of memory usage, although as previously explained part of this is the actual stand alone player, not the movie it loads. Once I start navigating the movie, each interaction with the navigation adds between 4-12K to the memory usage. This seems to occur BEFORE anything else happens, i.e. it is a direct result any of the onPress, onRollover or onRollOut events being dispatched, and the generated clip that constitutes the NavItem that is being interacted with having its colour changed. In addition that memory never seems to be released?

Of course this is only the Windows Player, and of course it is a different version. But as I continue to work on this experiment I can safely say this form of memory leak is certainly not an isolated case. I have witnessed my 100K flash movie continue to consume many megabytes of memory once i began to load the XML data. Yet at no point does the memory get released. If there is anything close to this level of leakage within the PSP version of the player I fear that any serious development may well be impossible at the moment on this device.

My next development track will be to explore returning to more OldSkoolFlash development and construction methods, relying less on the dynamic scripting I tend to use today. Bring back, the invisible button, jump movie, and any number of other flash techniques either I developed or help others develop almost 10 years ago.

3 thoughts on “Further Flash Development for PSP”

  1. Nice post m8. I’m currently running a few test on the PSP too so will let you have the files once I’ve done with them.

    I’m of the same opinion that this is an oldskool Flash 3 style process…Lets see what we can do.

  2. What I’ve had to do with Flash Lite 2 is “spread out the damage” as I like to call it. The Flash Lite 2 player is unbelievable in what it can do with such little memory if you treat it nicely. By nice, I mean, instead of attaching 15 movieclips/components in 1 frame, you attach 15 across 15 frames. You basically just an onEnterFrame to attaching a list of movieclips. This works really really well. Slow? Yes. But it works everytime and the device can handle it.

    Additionally, I’ve been really stringent on variable usage. For example, after removing a movieclip, I’ll delete it’s variable. I’ll throw deletes on ALL variables not being used anymore.

    I think a lot of existing projects people think can’t possibly run on a device CAN if they just spread the damage.

  3. Becuse the development so far has all taken place through mtasc i havent made any use of the time line.

    As I mention this is where i intend to move back to.

    I will post the code i have produced for this experiment soon. Thoughout the classes i have constructed i have been very strict with teh deletion of Vars as they become redundant, however because I have also tried to remain fairly faithful to the Adobe code frame work some of the classes I have imported may not be quite so particular about the removal of un-used references.

    Even so, as a long time developer it is disapointing to once more be discussig how to work round limitations of a flash delivery or platform, rather than being able to just pick it up and run with it.

Leave a Reply

Your email address will not be published. Required fields are marked *