Code code code… Profile

October 17, 2012

Tonights big wins:

Selective colliding in Nape : I don’t want the enemies to collide with the hero, but I want to sense when the objects touch. I also want the enemies to fall through the floor when they die. I got all this working with 3 CbTypes and 2 InteractionFilters

Enemies Die: And recycle themselves to be used again.

I also started playing with Monocle this week. It is the new profiling tool Adobe is working on. Monocle is hella sweet. Using it I cleaned up a lot of inefficiencies in my code. Some stupid mistakes it found:

  • Sprite.width and Sprite.height calls are really bloody expensive in Starling. I mean I knew they were expensive thanks to this article. But I never would have suspected I was eating 5ms per frame with them.
  • Sprite.flatten() is really bloody expensive. I was being a bit too aggressive with flattening my Sprites. This was costing me 10ms on some frames.
  • touchable = false. No idea why this isn’t default flagged to false on Starling display objects, but I was eating up 5-10ms some frames on my Nexus One while it tried to determine which DisplayObject should handle a touch event. I now only have my TouchPad Quad as a touchable object within the Scene (and of course any UI stuffs).
I also profiled my previous Roller Derby 20xx code as written in Flixel. It gets 30fps on my Nexus 7 which is pretty sweet considering zero optimizations. So my goal with this Starling/Nape work is to rebuild that game using the GPU rendering and get 60fps.

Oh yeah, and to utilize Monocle best I’ve moved over to Air 3.4 and Flash Builder 4.7. So far… I’m liking the stricter compiler.

Leave a Comment

Previous post:

Next post: