2D Toolkit Forum
2D Toolkit => Support => Topic started by: renjian212 on December 29, 2014, 05:31:54 am
-
Dear tk2d support,
We're developing an online multiplayer racing game, which is quite sensitive on frame rates. But recently we have run into problems where GC takes too much time, so we started some profiling to see our total memory allocations per frame. Surprisingly, we found that tk2dSpriteAnimator.LateUpdate is causing some amount of heap allocations every frame. The total amount of allocations each frame could be 1KB to 8KB, depending on number of calls. (See attachment screenshot)
frequent memory allocations could easily lead to unnecessary GC activity. Is there any way to avoid this?
-
For a more clear view about the call stack inside UpdateGeometryImpl method.
-
There shouldn't be any heap allocation unless there is a vertex size mismatch, eg. by using dicing / custom geometry. UpdateGeometry (the allocating function) is only called in this case, under normal circumstances only updatevertices is called. Make sure your vertex sizes match and you'll get rid of the allocation
-
Thanks for the reply! We found out that in our atlas some textures are diced but some are not. We re-applied dicing on all textures and the problem is resolved.
-
I would like to ask one follow up question - we still got the heap allocations when all our sprites are diced! And it turns out when the sprites of one animation are all diced, each sprite may have different vertex size, so the UpdateGeometry will be called frequently when animation is being played. So how we can enable dicing but meanwhile also keep the same vertex size? (we love dicing feature since it helped us save a lot of space on the atlas)
If vertex mismatch cannot be avoided with dicing...is it a good idea to implement a simple re-usable vertex array pool to avoid the allocations?
-
If vertex mismatch cannot be avoided with dicing...is it a good idea to implement a simple re-usable vertex array pool to avoid the allocations?
Its not so simple, you'll need to pool Mesh objects, then somehow free elements of the pool, etc.
Its easier to create a new sprite animator class (inheriting from tk2dSpriteAnimator) where instead of changing the sprite on yourself, you maintain a dictionary of sprite and turn a child sprite on and off. I have a straightforward implementation of this somewhere, if you're stuck let me know and I'll see if I can find it.