Gaming Your Way

May contain nuts.

Starling optimising

I was on client work so no progress yesterday. Today I thought I'd have another look at what I could do with Starling to try and save some cycles here and there.

We use sprite pooling like everyone else in the world. Rather than add/removeChild them, I just set visible=false as it should be quicker.

Because we have a ton of possible objects, even if they're not visible, I had a look at DisplayObjectContainer.render(). This loops through all the display objects running a check first to see if they're worth plotting ( i.e if visible=true, alpha>0, scaleX/Y>0 etc. ) and if so calls their render method to actually display them.


Now if we've got 500 particles running, but not displayed, it felt a little redundant still looping through them all just to not plot them, so I altered the visible method to spit the display object into one of two different Vectors, visibleChildren and hiddenChildren. If you change the visibility it's moved from one Vector to the other, which is a little costly and I want to look at that again. But, it means for our render loop we're now only looping through objects we know are visible, so it's a shorter loop and we've removed that extra visibility check which would happen for every object.

Other savings included lots of little things, for example there's a check to see if when you alter a x position has it actually changed. 99 times out of a 100 it will have, so there's no need for a check there every time.
Also because I use alpha a lot for the particles / explosions I had a look what could be saved there too, mainly "inlining" methods ( Not the compiler inline option, as that seems to break the Starling code ), VertexData.setAlpha was a really costly call before I cut it right back.

Just to make it clear, this isn't a criticism of Starling, it's a great piece of code which has to be all things to all people, and anyone can always look at someone else's code and speed it up, there's nothing clever about that.
In a perfect world I'd make my own Stage3D engine from the ground up, but I really don't know how many more Flash projects I'm going to do so I think it would be wasted time and just be a vanity thing.

Squize. 

Comments (3) -

  • Tronster

    2/27/2014 5:11:37 PM |

    I'd love to see some benchmark on your savings, and wondering if two vectors are really providing significant gains that maybe taking it one level further and utilizing linked list, as last checked they had potential to be twice as fast for traversing and significantly less costly for addition/removal (At least according to Jackson Dunstan's test in 2011: http://jacksondunstan.com/articles/1288 )

    • Squize

      2/27/2014 7:05:58 PM |

      Hey mate,

      I have recently added linked lists to the game ( It's a post a couple of days back ) but that was for my own code, but yeah you have a point, moving my Vectors over to linked lists seems a good idea.
      As to benchmarking it, I did have a simple "Plot rotating images to the stage" thing for Starling, but this is a different case where most of the items are hidden and I don't know how much motivation I have to knock one up :)

      It's a balance, as you don't want to throw too much work into it as before you know it the next version of Starling will be out and that's a lot of work to re-do.

      As the game progresses and I have more particles / sprites in there to really stress test I'll post anything I find savings wise on the blog.

  • Friv

    3/15/2014 4:56:08 AM |

    I support your thinking it's almost like I think, but I can not do it. I hope that you will do and have a video to share with me

Comments are closed