Poor Performance when moving a grid of sprites?

[eshan.mathur]

Hey there!

I keep reading reports of great performance on iOS using 2D Toolkit leading me to believe I'm doing something incredibly performance intensive without knowing it, but I was hoping someone could see my problem. Basically all I'm trying to do right now is generate a grid of tiles with a texture on them. Each tile is 16x16, so on a retina iPhone there are 60x40=2400 tiles on screen. Kind of a lot, but hey. The simple goal here is to be able to drag my finger and make tiles that I collide with disappear, kind of like 'cutting' a path through them. There's one more important bit: the tiles all move. The camera itself (and I'm using a TK2D camera) moves to the right, and as it does so columns of tiles are all 'treadmilling' - i.e. disappearing from the left and reappearing on the right, giving the illusion of sidescrolling. As I "cut" through tiles, they get turned to inactive. Once they get treadmilled, they're turned back on. Each tile has a collider on it that I use to help out with that 'cutting' detection and that I'll need for collisions later.

In other words, all that happens is:

• Simple for loop generates a grid of TK2DSprites that cover the iPhone 4 screen.
• Move the camera at a steady rate.
• Move tiles that the camera moves past to the front of the dirt grid.

What's bugging me is that even if I turn colliders off completely on the tiles, the framerate on an iPhone 4 is atrocious. I don't know what it is because I haven't put in a framerate display script yet, but I know it's probably lower than 10 FPS. My question has a few parts:

• Is the very fact that I'm moving the camera over 2400 tiles at once the root cause of the problem?
• If so, what is a better way to approach this? Should I move the tiles instead of the camera, etc?
• Are there any texture or sprite or sprite collection optimizations I need to do that are obvious? I just followed the tutorial - I have one sprite collection with one sprite in it that I use for the tiles.
• Will those colliders add a whole new layer of complexity to the problem or do I not really need to worry all that much about those?

Thanks!

[unikronsoftware]

Hey,

A few things to work out whats going on.

1. First, replace the tiles with the default Unity box. Do you get performance issues then? I suspect you would, as the tk2dSprites are just plain meshes there. If not, that implies that something could be wrong with the dynamic batching, etc.

2. If you have Unity pro, just turn on the profiler and see what is taking up the most time. It should be obvious even when running on Mac. You obviously have a pro license on the mac anyway, so you could try that. Also, if you don't have iOS Pro, you can enable the profiler in one of the .mm files in xcode, can't remember which one offhand. That'll tell you whats taking the most time.

3. These aren't animated sprites are they? Animated sprites do take quite a bit of time to update, so having a lot of them all animatiing at the same time could be bad - there are ways around this.

4.  I dont know about the colliders - test #1 and #2 will tell you if the colliders are the slow bits.

Let me know what you find and we'll take it from there.

[eshan.mathur]

I'll test those out within the hour and let you know. Quick side question: I'm having trouble getting a text mesh to show up. It's Z-value is above that of the tiles and according to the camera preview it's positioned properly, but it won't show up. Any ideas? I wanted to make a quick FPS counter.

[unikronsoftware]

Is it not showing up when running in game? Or is it broken in the viewport too? Its hard to tell what has gone wrong there from your description, any number of things could be wrong.

[eshan.mathur]

Just kidding. I experimented in scene view and it looks like the TK2D camera preview isn't accurate or scaled properly at all. I had to move and scale the text mesh in Scene view to make sure it was the right scale and position for the camera. Let me know if there's a better way to do that.

[unikronsoftware]

Are you on 1.76 final + patch1? That works around that Unity bug that incorrectly draws the preview window. If not, I suggest updating

[eshan.mathur]

I'll look into that! I'm trying to implement your first suggestion - how would be the best way to go about replacing sprites with native Unity objects? Should I use a plane with a texture on it?

[unikronsoftware]

just a standard untextured box will do. Make it the same size as the sprite and you're good to go.

[eshan.mathur]

I'm trying to do it with a plane but running into really strange rotation issue. I suppose I'll try it with the box!

[eshan.mathur]

So I ended up actually trying it with something more efficient than all - a simple plane rendered out of maya composed of two triangles. That's it. I ended up getting my tiling and cutting code to work with it. It's actually marginally better than 2D Toolkit - I get 5k vertices and 3 draw calls vs what I was getting using TK2DSprites (10k verts and 8 draw calls), but the framerate on a phone is still around 4-7 FPS. Really bad Also, these are not animated sprites.

Agh! I really need this to work smoothly. What are some next steps?

P.S. I will update to the newest version as soon as I get approval for the usergroup.

[unikronsoftware]

Updating to the newest version isn't going to help, as this test has proven it isn't the geometry rendering, etc. To narrow down the cause of this sensibly, the best option is to start doing those profiler tests I mentioned earlier.

[eshan.mathur]

Okay I finally figured out how to hook up the Unity profiler to the game while it's running on the phone. Basic results were basically this from CPU, with colliders on:

Avg Frame Rate: 4-5 FPS.
Physics.Simulate - 65%-75% Total Usage, 114ms-175ms.
Camera.Render - 25-30% Total, 50-90ms.

The rest doesn't compare to those two all that much performance wise. I then turned off colliders, and noticed at least some improvement in performance:

Avg Frame Rate: 12-15 FPS.
Camera.Render - 93% Total, 55ms
Physics.Simulate barely registered.

Obviously the colliders are a problem but I will screw around with them in a bit. The much bigger problem is that I'm not even able to render and move a grid of 60x40 physics-less tiles on an iPhone 4 at a rate better than 12 FPS. I've also tried locking Unity's Application.targetFrameRate to 30, but no noticeable improvement.

Any thoughts on why it's going so slow?

[unikronsoftware]

Well with camera.render taking 55 ms the most you're going to ever get is 18fps so what you're seeing is expected. Now we need to work out why its taking so long to render and what specifically in camera.render is taking up all the time. Does this not expand any further?

[eshan.mathur]

Sorry! I didn't look into the breakdown. Basically, most of it is being taken up by Render.TransparentGeometry and other alpha based operations. I'm not sure what they all mean and I'm sure you have a better idea, but if my sprites are all using opaque textures and shouldn't have any transparency to them, why is there so much work being done on transparent geometry? Is the map not being generated properly?

Here's a screenshot:

[unikronsoftware]

Render.TransparentGeometry hasn't got much relevance to the gpu performance, its just the path Unity uses for these. The default materials in 2D Toolkit are transparent, hence them appearing in this stage. Transparent materials will affect gpu performance, and this is easily sorted. But this isn't the issue you're seeing here. To eliminate it, switch to your maya object test, and replace the material with a newly created untextured one.

Culling is taking a lot of time followed by actually rendering the meshes. In this case, it looks like the main overhead is dynamic batching (and drawing) all these objects. What exactly do you do with these sprites? Can you send me a webplayer or something so I will have a better idea of whats going on? If possible, send to support@unikronsoftware.com.

In any case, it looks like the overhead is caused by the sheer number of sprites. This can be sped up in one or more ways, the best way is really dependent on your needs here.