Jump to content
Search Community

Loading packaged assets

MediaSaints test
Moderator Tag

Recommended Posts

Hello folks!

 

I've got a project using LoaderMox to handle all the asset loading, and it does that impressively.

 

We have a large number of assets of various sizes, and to-date we have loaded each of them individually (in queues of course, by with a long list of files). We've now got to the point where we care about our loading profile online, and loading so many relatively small files is killing us with latency. We are looking at packaging the assets together into groups, but I'm hoping to find a way to drop in handing for packaged files while retaining the ability to run without the packages, to make it easier to continue development.

 

Ideally I'd like to be able to load in a package (perhaps a zip with a set of files, although I keep thinking that I should be using a swf as a library) and have the contents of the package appear as though they had been downloaded individually as far as LoaderMax is concerned, so I could keep the loading code as it is, and simply bolt on a package load in front of what is already there.

 

This sounds to me like something that might already have been done by someone...

 

Thanks for any tips, suggestions, or pointers.

 

Liam Routt

Media Saints

Link to comment
Share on other sites

LoaderMax doesn't directly accommodate zip files, no. I would suggest putting your assets in a swf which is a compressed format and should help you with the latency for sure. If you dump assets on the stage and name them, you can use SWFLoader's getSWFChild() method to grab 'em easily. DataLoader can be used as a generic loader too, even for binary stuff. Hope that helps.

Link to comment
Share on other sites

I realize that LoaderMax doesn't handle zip files. I was prepared to handle the zips myself.

 

I'm trying to work out whether I can load the assets in such a way that LoaderMax would identify them as already loaded if I made a normal load request. I'd like to leave all my existing asset loading code in place, and just pre-load the assets from a package, when one was available.

 

I suspect that there isn't an easy way for me to take an asset and convince LoaderMax that it has a url and has already been loaded, so that it will use it when that url is requested later.

 

Liam Routt

Media Saints

Link to comment
Share on other sites

We're going ahead with the packaging solution that we were first considering, as it seems that it should work.

 

In the LoaderMax code, the load itself boils down to a call to _loader.load(...). If we have the binary data for an asset we should be able to replace that call with a _loader.loadBytes(...) providing the cached data, rather than making another load.

 

I've defined an interface to a notional file cache, which responds to a query looking for a particular url. If we find we already have the data from that file we pass back a ByteArray with it, otherwise we pass back a null and the usual load takes place.

 

We are implementing a file cache which will be filled by loading a zip file, or several zip files. There will be a dictionary created in the cache which allows it to locate data files from the url in a request.

 

This scheme should allow us to make the pre-load of the asset package optional, as anything not found in the cache will be loaded as normal.

 

The results have been promising so far, but we're still in the midst of implementing the cache (and zip file processing).

 

Liam Routt

Media Saints

Link to comment
Share on other sites

Well, our package cache seems to have worked.

 

Here is a rundown of the small changes we've made to the loaderMax code.

 

Added loading/IFileCache.as:

package com.greensock.loading
{
   import flash.net.URLRequest;
   import flash.utils.ByteArray;

   /**
    * ...
    * @author Liam Routt
    */
   public interface IFileCache
   {
       function findAsset ( url:URLRequest ) : ByteArray;
   }

}

 

Change to loading/LoaderMax.as:

@@ -152,6 +152,8 @@
		public static var defaultContext:LoaderContext;
		/** The class used by ImageLoaders, SWFLoaders, and VideoLoaders to create the containers into which they'll dump their rawContent - by default it is the com.greensock.loading.display.ContentDisplay class but if you're using Flex, it is typically best to change this to com.greensock.loading.display.FlexContentDisplay. You only need to do this once, like 
import com.greensock.loading.LoaderMax;
import com.greensock.loading.display.FlexContentDisplay;
LoaderMax.contentDisplayClass = FlexContentDisplay; **/
		public static var contentDisplayClass:Class;
+
+        public static var fileCache:IFileCache;

		/** @private **/
		protected var _loaders:Array;

 

Changes to loading/core/DisplayObjectLoader.as:

// in the headers
+    import flash.utils.ByteArray;

@@ -93,15 +94,25 @@
				}
			}
			if (Capabilities.playerType != "Desktop") { //AIR apps will choke on Security.allowDomain()
			Security.allowDomain(_url); 
			}
-			_loader.load(_request, _context);
+
+            var bytes:ByteArray;
+
+            if ( LoaderMax.fileCache ) {
+                bytes = LoaderMax.fileCache.findAsset(_request);
+            }
+            if ( bytes ) {
+                _context = null;
+                _loader.loadBytes(bytes, _context);
+            } else {
+    			_loader.load(_request, _context);
+            }
		}

		/** @inheritDoc **/
		override public function auditSize():void {
			if (Capabilities.playerType != "Desktop") { //AIR apps will choke on Security.allowDomain()
			Security.allowDomain(_url); 
			}
			super.auditSize();
		}

 

Basically, this adds a public var to LoaderMax which allows the provision of a file cache with the one interface function which returns either null or the ByteArray for the display object as found in the cache.

 

Our only real stumbling block here was having to provide a null context for the loadBytes call, otherwise what we loaded wasn't able to be used as it would have been after a normal load.

 

It is left to the integrator to provide such a file cache, and to populate it. We managed to easily put together a dictionary-based zip file processor which was able to accept the url and determine whether the relevant file was in one of the zips it had processed. We have both persistent and temporary zips in our cache, so that we can flush some data and keep the stuff we know we will want to use again.

 

I hope this approach is of use to someone else.

 

Liam Routt

Media Saints

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...