I'm running into some some "draw" performance issues on the iOS phone simulator. I believe I've narrowed it down to my usage of render targets, so I'm looking to see if anyone has any good suggestions on how I could improve frame rate, before I scrap render target usage.

I set out to use render targets because different sections of the game have a zoom capability, and also I just wanted to be able to draw render targets on a scale with the viewport (as opposed offsetting & scaling through different sprite batches). 

Everything runs great on my reasonably old windows PC. I put diagnostic stopwatches at the beginning and end of both my Update/Draw calls, and both never run for more than 1-2 ms. However, on the iOS simulator, the draw method takes on average 40ms. I haven't tried it on an actual iOS device, but I'm assuming it could be worse if anything. I'm using the 2011 Mac Mini, with the Radeon graphics card (if that matters).

The game itself doesn't have a lot of textures being drawn out to the render targets during each Draw call, probably 40-50 textures on average, total. I use at most 3 render targets at a time, which the sizes being 480w X 320h.

Any suggestions would be greatly appreciated. In the meantime, i'm going to get the game running without render targets to see the difference.

Performance in the simulator should never be used as an indicator of performance on a device.  There are many differences in performance between a desktop GPU and a mobile GPU, so rendering performance should always be tested on a device.

Yes, simulator and device are very different.  I would try to get your code on a real device ASAP to get a realistic idea how it behaves on hardware. 

The first thing to look at is if you are incurring a lot of GL state changes.  A state change occurs primarily when you switch textures or start a new spritebatch.

You can help things dramatically by using texture atlases to minimize GL texture swaps.   Also, minimize spritebatch counts as much as possible.   If you have several different classes with spritebatch logic in them, look into a spritebatch service implementation where the service provides the working spritebatch and each class ends up using the same one.

Thank you both for the suggestions, it is greatly appreciated. This is my first game, so I am definitely learning as I go! I haven't bought a licensed version of MonoTouch yet, but I will this week and get it on an actual iOS device very soon.

Within the code, I do just use one SpriteBatch instance throughout the lifetime of the game, shared by the all the render target drawing as well. I do, however, have every image held it its own XNB, so I believe the GL state changes are something I'll have to reduce by making a large atlas file.

Odanrot wrote:

Thank you both for the suggestions, it is greatly appreciated. This is my first game, so I am definitely learning as I go! I haven't bought a licensed version of MonoTouch yet, but I will this week and get it on an actual iOS device very soon.

Within the code, I do just use one SpriteBatch instance throughout the lifetime of the game, shared by the all the render target drawing as well. I do, however, have every image held it its own XNB, so I believe the GL state changes are something I'll have to reduce by making a large atlas file.

If you target iphone 3GS or above (which I would recommend since you are starting out....performance and memory issues on 3G or older can be tough), you can have a texture up to 2048x2048.  If you can fit all of your textures on that, then I think your performance could be improved.