Best way to dice sprites for iOS?

[NMD]

Hello, I'm working on optimizing a game and have some sprites that need to be diced for the sake of texture wastage.

I'm hoping someone could provide some info on how to determine the best way to dice things particularity as it relates to performance on iPad3/4.

Thanks so much!

[unikronsoftware]

In most cases, dicing saves more texture space than performance. Start with 64x64, adjust up a notch or down to see what works best for you. What you want to do is try to get rid of the most of the empty space. It really is very dependent on your texture content, so experiment to see what works best

[NMD]

Ok thanks.

My concern is, this game is already performing poorly on the iPad. I guess a more to the point question would be. Do I need to try to strike a balance between how much texture space I'm saving and the amount of quads being used for the sprite? And how does fillrate play into it? You'll have to forgive me, I'm new to iOS. Thanks again!

[unikronsoftware]

Unless you're drawing LOTS of polys, you're not going to get much overhead from the additional quads. Its going to be insignificant in the grand scheme of things. I mean you don't wanna go overboard and tile to 2x2 pixels or something, that wouldn't be very wise, but a 1024x1024 texture diced to 64x64 = 256 polys...

You are much more likely to be fillrate bound on iPad. It could potentially save fillrate if there is any empty space in your texture which it gets rid of, no diff otherwise.

[NMD]

Ok, again, thanks so much.

Could you maybe provide some general advice on fillrate? I understand that fillrate is how many pixels the gpu can pump out. But beyond that I'm having trouble finding much info on how to optimize this thing.

Part of the issue with this game is the client wants lots of high res sprites on different layers. And some are oddly shaped(thank god for dicing bc they demanded that this massively wide platform thing not be sized down anymore).

[unikronsoftware]

Well, you seem to know all there is to know
The key thing - Reduce overdraw as much as possible. Overlapping sprites = really bad.



There is one more optimization you can do, though it is not automated in tk2d as it is harder to control and won't work in all cases.

Lets say you have a bunch of sprites which are predominantly solid with feathered edges or something. What you do is split up the texture into 2 textures, the first being the solid bits only - 1-2 pixel edge, and the second is just the feathered outline. All you do is go into photoshop edit the alpha channel and cut out a huge alpha hole where the solid bits are in the 2nd option.

In tk2d, make sure dicing is turned on for the second texture - it will nicely get packed into small thin polygons, and the first doesn't need tiling if its rectangular. On the first, override the material to a solid material (tk2d/SolidVertexColor) (http://unikronsoftware.com/2dtoolkit/doc/tutorial/multiple_materials_in_a_sprite_collection.html). Now you can create a composite sprite, they both should have the same parameters & anchor, so will perfectly complement each other when placed at the same location.

If you have a bunch of sprites which are mostly solid, you will save a TON of fillrate this way.

[NMD]

Awesome info man, thanks.

I was aware the overlapping sprites increased fill rate, obviously bc it has to process that pixel n times. And again, something that the client insists on, lots of floating parallax things in the level and the bg. 2dtk has already helped me get the frame rate way up but still trying to sort out these few remaining bottlenecks.

[NMD]

Forgive me if I should make a new thread but this is a related question.

How does dicing sprites affect performance on animations? Is the entire mesh being changed every frame? And how does that affect memory?

Thanks again!

[unikronsoftware]

You shouldn't use diced sprites on animations. It should trigger a warning telling you about performance costs, but if it doesn't maybe I missed it in the new animation editor interface...

As with most things, this isn't definitive advice. If your game has fairly few animatedsprites, then using diced sprites won't affect performance too much in your game, though you will eventually hit a GC collect.

[NMD]

Hey thanks again, I never actually noticed any warnings. I read in the documentation that scaling a sprite or doing something that would cause the mesh to change is expensive so I assumed the same was true for diced sprites. Guess I was just hoping that there was some super cool optimization 2dtookkit did when animating diced sprites, bc these people are killin me when it comes to wasted texture space, hehe.

[unikronsoftware]

You could try it, its easy enough to turn off if its taking too long

[NMD]

Hey, I actually already had most of my enemy animations diced already to save a bunch of space, and they worked pretty well as most of them are only a few frames, but I was starting to notice about a 10 fps drop when a lot of them came on screen and my memory was gradually increasing beyond acceptable limits. I may try to get away with dicing the character anims as I expect that will have less of an impact and I was able to save half an atlas by dicing the character anims.


PS> The memory hike is not from having more enemies at once, most of my objects are pooled. Although in all fairness, the enemy script they use is a mess and could be doing something crazy but I haven't had time to properly profile that code. Anyway, I'll do some testing with and without dicing different anims and see where I land. Thanks again.