I've had a problem in my game for a long time. I have an AIR app that uses almost exclusively ATF files on disk. I learnt that with a large library of assets you either:
- Preload all the assets before having to display them, incurring a lot of memory use, long loading sequences, but smooth runtime;
- Load assets as you need them, keep memory down to the minimum, but keep having runtime framerate chugs due to URLRequests (the infamous yellow bars on Scout).
You just run a worker thread to handle all the disk I/O, et voila! The nasty chugs are gone and you get to keep the GPU memory down.
I tested it on the latest AIR19 Beta on Android, iOS, Win and Mac.
Here's how it works:
- Create a Worker
- If you're using the starling's AssetManager like I do, you just extended the "loadRawAsset" function to intercept any asset that needs a URLRequest.
- Send a message to the worker with the assetPath of the file you need, making sure to keep a Dictionary reference of said path for the callback later on.
- Run code similar to "loadRawAsset" on the Worker
- Once the load is complete, send back to the Primordial Worker (your main app) the bytearray and assetPath, which will be used by the Dictionary to locate the callback function.
- Run the callback function sending the bytearray, which will connect to the "complete" function of "loadRawAsset", concluding the load and starting the texture memory uploads that Starling deals with oh-so-very-well.
I'll be happy to provide code for all of this, I just need to clean it up and make sure it works with context losses etc.
And those I/O slowdowns are now the burden of the Worker:
The biggest downside here is that loading on the Worker instead of the Main app takes a little bit longer. You definitely notice it but it beats ruining the framerate while swiping long lists!