XNA, SpriteBatch: Slow when rendering lots of sprites?

Question

I've just now tested rendering a lot of sprites using XNA's SpriteBatch class. What I basically do is this:

Somewhere in the code, I have a list which contains all sprites that have to be rendered. I prefilled this list with 2500 Sprites, all of which have the same rotational angle, texture, position etc.

I then draw them like this:

    spriteBatch.Begin();
    foreach (Sprite spr in sprites)
        spriteBatch.Draw(spr.Texture, spr.Position+spr.Center, spr.SourceRect, spr.Color,MathHelper.ToRadians( spr.Rotation ), spr.Center, spr.Scale, SpriteEffects.None, spr.Depth);

    spriteBatch.End();

and I'm getting really poor performance. I only average about 15FPS with my Radeon HD 6850 graphics card and i5 2500k CPU.

This is very surprising to me, since I average about 70 FPS doing exactly the same thing with my own custom OpenGL engine, which uses old OpenGL rendering (meaning one draw call for every single sprite). I actually expected XNAs rendering to be a ton faster, since it draws everything in one draw call.

Am I rendering this the wrong way? Playing around with SpriteSortMode settings has made almost no difference, some of them just make it a tiny bit slower (depth sorting etc.).

Answer 1

I am not sure, but I think you have each sprite with an instance of its own texture. Meaning instead of doing 1 sprite batch, you are doing 2500 sprite batches. Try replacing spr.Texture with a single local Texture instance.

Also you do arithmetic and call functions from inside the spritebatch function call, which could slow it down more. Try to have all your calculations done somewhere else, and try to store the rotations in the correct format instead of what you are doing.

Answer 2

Take a look at this question and answer: Optimizing an XNA 2D game.

I would guess you are either hitting a fill/texture-fetch limit (a GPU limit) or a batch limit (a CPU limit, as described in that linked answer).

Try setting the position of all of your sprites off-screen, and seeing if it makes it faster. If it does, you're hitting a fill limit. You need to reduce the amount of over-draw or simply reduce the amount of stuff you're drawing.

If you're hitting the batch limit, then SpriteSortMode.Texture is likely to give you an enormous speed-up. If you cannot use this as a real-world solution, then the correct solution is to use sprite-sheets to reduce texture swaps. (Of course, if you're only using one texture already, or your textures are pre-sorted, then this won't help.)

I seriously doubt the maths operations are dominating your CPU usage. There are faster alternatives to the + operator and ToRadians, but it's not like these are slow! (If you're accessing each sprite's information through properties - each property access has the same overhead - you'd be better off switching to fields rather inlining those functions.)

One thing that might be eating your performance is cache coherence. If each Sprite is a reference type (ie: class), then you're likely suffering a huge number of cache misses as you loop through them. Try making sprites an array of value types (ie: struct). (see this answer)

A possible worst-case is if they are already value types and you're accessing them through an interface - in that case you're doing an epic amount of boxing (slow and allocates memory).

(Of course, there could be other things wrong, but that's all I can think of at the moment based on what you've posted.)

Answer 3

About XNA sprite sheet example: https://stackoverflow.com/questions/726921/recommend-sprite-size-for-games-xna

This also may be usefull to you.