Hi guys,
as you may know we’re using Liaocheng’s particles and started optimizing Delta Strike for performance and memory usage using Monocle.
One of the things that troubled us was that the particle effects we use for explosions and the like literally froze, especially on the iPad, for more than a second when executed for the first time.
Liaocheng basically seems to have followed the general design pattern of lazy getters and on-demand computations (using dirty-flags, etc.), which is a good thing for kick-starting our game into a smoothly running update loop in idle mode, but which is bad when the real action actually begins. That is since everything is initialized on the fly, which happens at a point in our game where we need a maintain a steady and high frame rate already.
Now that all of away3d is based on those same principles, it is in general quickly loaded and allows for a smooth loading process. However, the real juice gets spilled once you have a user all geared up to play with high expectations for action and battle, but which then experiences a few disappointing seconds of low frame rate, low to virtually no responsiveness from the system and some more stutters once the garbage collector kicks in. On top of that, the iPad sometimes rage-quits with an error log indicating a timeout from the app as it was eating up so much CPU time iOS believed it was stuck in an infinite loop.
I hope my tales of performance and garbage collections here make sense to you. Long story short, precaching some resources in a controlled manner during boot up has now become one of my most favorite choices on my wish list 
What I achieved so far was to hack some additional methods into Liaocheng’s particles, which create most of the required GPU resources, like bitmap textures, assembling program3Ds and creating any kind of buffers as soon as all required file resources have finished loading. This essentially shifts the workload from first time of execution to the boot up phase of our game.
This works nicely, especially since Liaocheng shares all such resources among all clones of the same particle effect, so jump starting resource creation positivle affects all following executions.
Now the tricky thing is that such precaching could again stall the entire app for quite a while before it’s finished. I guess the same reason why asset parsers have been green-threaded no to lock up an entire enter-frame.
In Delta Strike we use our own green-threading system in which the bulk work of all initial computation as well as object life cycles (creation, destruction, pooling, reset) are done in the background while simply using whatever time is left after the renderer is done. This requires a lot of code to be executed asynchronously and increases programming complexity, but it keeps the frame rate nice and shiny =)
I believe Richard was it that was thinking about general green-threading in away to accommodate multiple concurrent asset parsers. Is that still a discussion that’s going on?
Have there been any thoughts about Adobe’s concurrency API? Unfortunately it will not be supported on mobiles for the time being, and shared memory via byte arrays will only be released after 11.4. It would be the perfect solution for resource allocation / precaching, but would still require a fallback solution for mobiles.
As with a project of the proportions like Delta Strike has grown to it becomes more and more paramount to be able to control very precisely whatever little CPU time low-end platforms like the iPad offer. In my opinion this will also become crucial for away once it’s going to be used in other professional and especially commercial projects that do have only little margin for error and inconveniences as well. As you know, especially freemium games need to deliver a rock-solid first positive impression.
So ... what do you think? Richard, David, Rob (who is now plagued with the money-counting business side of dollar-signs-in-your-eyes life? 
:D )? =)
Thanks and cheers!
Alex
