precache/jump starting resources

Software: Away3D 4.x

Avatar
Alexander Seifert, Moderator
Posted: 21 August 2012 03:54 PM   Total Posts: 129

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 smile

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? wink:D )? =)

Thanks and cheers!
Alex

 Signature 
signature_image

http://www.deltastrike.org

   

Avatar
Cheng Liao, Administrator
Posted: 22 August 2012 06:34 AM   Total Posts: 116   [ # 1 ]

Hi Alexander
I’m very agree with you. The createVertexBuffer , createIndexBuffer and others may consume a long time . This will also happen when device loss and then all objects in the view will need to recreate their GPU resource , it will consume a few seconds in desktop .
Regards!

   

Richard Olsson, Administrator
Posted: 22 August 2012 07:22 AM   Total Posts: 1192   [ # 2 ]

Alex, I’m not sure what your question is exactly? Shorter is often better. wink

   

Avatar
Cheng Liao, Administrator
Posted: 22 August 2012 07:33 AM   Total Posts: 116   [ # 3 ]

He want a function that once call it , it will create all resources on GPU of a DisplayObject , instead of making them created auto in rendering loop . smile

   

Richard Olsson, Administrator
Posted: 22 August 2012 07:38 AM   Total Posts: 1192   [ # 4 ]

Ok, then please file a feature request on GitHub. Please try to be concise in what you want exactly. Any other questions can be asked here.

   

Avatar
Alexander Seifert, Moderator
Posted: 22 August 2012 07:55 AM   Total Posts: 129   [ # 5 ]

Thank you Richard,
thank you Liaocheng! =)

Yes, this is better moved to the feature requests in Github. I was asking about what Liaocheng wrote, about a function, actually a whole mechanism, that creates GPU resources before they are needed the first time. Hence the subject “precache/jump starting resources”.

The reason I posted it here was for the purpose of discussion. To put it out there and see if someone else also has this concern and for all readers here to maybe get a statement from some official core developer to share =)

Cheers!
Alex

PS: in general, since I missed it, is Github now the place for _everything_ code related?

 Signature 
signature_image

http://www.deltastrike.org

   

Richard Olsson, Administrator
Posted: 22 August 2012 08:02 AM   Total Posts: 1192   [ # 6 ]

GitHub is the place for issues (bugs and feature requests.) You can still discuss them here of course. I just did not understand what exactly it was that you wanted, because you wrote this huge post where you seemed to first ask a question and then answer it yourself, over and over again. If you have any outstanding questions from the original post that you would like answered, please reiterate them in a concise manner.

   

Avatar
Alexander Seifert, Moderator
Posted: 22 August 2012 08:13 AM   Total Posts: 129   [ # 7 ]

My apologies =) I’m know for starting babbling comes the end of the day and I still refuse to leave the office ... wink

- Do you recognize the need for precaching GPU resources?
- Did you ever make plans / were thinking about general green-threading in all of Away3D? (I.e. not only for multiple concurrent asset parsers)
- Same for Adobe’s concurrency API?

Thanks! =)

 Signature 
signature_image

http://www.deltastrike.org

   

Avatar
80prozent, Sr. Member
Posted: 25 August 2012 02:03 PM   Total Posts: 430   [ # 8 ]

hi
i would be very interested in a green-threading functionallity for away 3d that would allow me to do calculations on large meshes without freezing my app.
would that be possible ?
or would i have to implement most of the green-threading logic within every calculation anyway ?

 Signature 

sorry…i hope my actionscript is better than my english…

   
   

X

Away3D Forum

Member Login

Username

Password

Remember_me



X