Timeline for XNA, SpriteBatch: Slow when rendering lots of sprites?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 19, 2011 at 1:53 | answer | added | Andrew Russell | timeline score: 9 | |
| Jun 18, 2011 at 21:33 | comment | added | Jonathan Connell | @heishe glad you found the problem | |
| Jun 18, 2011 at 21:30 | answer | added | Romanenkov Andrey | timeline score: 1 | |
| Jun 18, 2011 at 21:25 | comment | added | AttackingHobo | @heishe 64x64 = 4,096. 200x200 = 40,000. Of course 64x64 will run faster. At 200x200 it will have to transfer and draw almost 10 times as much data. | |
| Jun 18, 2011 at 21:24 | history | tweeted | twitter.com/#!/StackGameDev/status/82197025311031296 | ||
| Jun 18, 2011 at 20:48 | vote | accept | TravisG | ||
| Jun 18, 2011 at 20:47 | comment | added | TravisG | Hello, another update, and finally (I guess) a solution. I think the size of the texture was the problem. I reduced the size of the texture to 64x64 (from 200x200 previously) and it now runs at about 60 FPS when drawing 50000 sprites. Thanks to all of you. I wasn't aware that bigger textures actually made that much of a difference (I knew that using, lets say, 1028x1028 textures costs a lot of performance, but I didn't think that a small difference of 120x120 texels makes that much of a difference). | |
| Jun 18, 2011 at 20:30 | comment | added | TravisG | Alright, manually saving the texture to a tmp texture before rendering and then using it for all spriteBatch.draw() calls significantly increases the performance, but it again starts dropping to 15 fps at around 7500 sprites. This still doesn't make a lot of sense to me though, as spr.Texture should return a reference to the used texture (although the reference itself is copied by value of course). I will no try to change the other stuff to see if I can improve performance further somehow. | |
| Jun 18, 2011 at 20:17 | comment | added | Jonathan Connell | I just quickly tested my engine, I drop to about 30FPS with 50000 calls using the same instance to a 64x64 texture, with quite a few instructions to calculate position, etc. I would check the size and as @AttackingHobo says, try to make sure you reference the same Textures. It seems strange though, because the ContentManager automatically returns a texture reference if it is already loaded... | |
| Jun 18, 2011 at 20:09 | comment | added | AttackingHobo | @heishe, It will only do that if you have everything in one texture. If you are sending 2500 unique textures to the GPU it will do a spritebatch for each one. | |
| Jun 18, 2011 at 19:57 | comment | added | BlueRaja - Danny Pflughoeft |
Also, when doing performance tests, make sure Game.IsFixedTimeStep and graphics.SynchronizeWithVerticalRetrace are set to false.
|
|
| Jun 18, 2011 at 19:51 | comment | added | TravisG | Yes, it does run fast again. Around 6500-7000 FPS without the code. I have not tried the other things yet, but I will try out the suggested changes (also the ones AttackingHobo suggested) now to see if it changes anything, however I'm dubious if it will, after all drawing is mostly a graphics card thing (the cpu<-> gpu pipeline limitations shouldn't be a problem since spriteBatch is supposed to transfer all data in just a few calls) and those other things are CPU calculations. | |
| Jun 18, 2011 at 19:41 | comment | added | BlueRaja - Danny Pflughoeft |
If you remove the code shown (and only the code shown), does the game go fast again? Are you adding the sprites to sprites every frame, or only once? Have you tried removing the +spr.Center and Math.ToRadians to see if the math calls are slowing it down?
|
|
| Jun 18, 2011 at 19:31 | answer | added | AttackingHobo | timeline score: 6 | |
| Jun 18, 2011 at 19:21 | history | edited | TravisG | CC BY-SA 3.0 |
edited body; edited title
|
| Jun 18, 2011 at 19:16 | history | asked | TravisG | CC BY-SA 3.0 |