I’m starting development on a new indie game, and I thought I should consider Unity as a possible platform to build the game in. I’m currently researching and testing some stuff…
From a little looking around, I’m currently thinking that the 2d performance (rendering 2d sprites) of Unity is much slower than a normal platform?
Random example:
I can render about 8,000 32x32 sprites (with alpha) in XNA at over 400 frames per second.
From some research it looks like Unity can only render about 500 sprites at under 60 frames per second (I haven’t tested this myself, but found someone’s comparison of different 2d frameworks, including SM2, ex2d, etc.)
(here is the link The Secret Pie: Comparison of 2D frameworks for Unity 3D)
Is this true?
I know Unity really isn’t build for 2d, but I thought it wouldn’t be quite as slow as this comparison shows…?
I have no idea what size these animated sprites are… as the person who wrote that comparison only tells the size of the single background sprite (which is pretty much irrelevant as he’s only rendering that once).
I don’t want to eliminate Unity until I’m sure it’s a no-go, as some other aspects look pretty cool
So I guess I’m asking - does anyone know how many sprites can be rendered with good performance?
(any 2d developers out there using lots of sprites? :P)
Please remember Unity is a 3d engine with 2d added in by third parties. However, all that 2d stuff is running with the overhead of the 3d engine. XNA has no such limitation (at least, not that I’m aware of).
That article isn’t very useful as it doesn’t tell you much about the test.
There are also plenty of optimizations that you can apply to your own work that you can’t apply to a generic framework. Often these can be added to the framework too (I’ve applied lots of project specific updates to SM1 to boost performance).
As to exact numbers I’m not sure but I’d expect you can get quite a bit more out of Unity than the linked article suggests.
I put up 100,000 batched sprites (122x122 with alpha) on my desktop and my frame rate never dipped below 100fps. I guess I could take it higher than that, but I thought “yeah, that’ll do.”
That said, if you want a kajillion sprites on the screen at once, I’d look at other options beforehand, such as using the particle system.
If you have a kajillion sprites all animating with different textures and running collision and scripts and who knows what else, yeah, I can see the frame rate suffering.
Anyway, discussing how many thousands of sprites can be rendered on computer x isn’t really that helpful. Why not just download the free version of Unity and test to see if it fits your actual needs or not?
Also it’s not really made clear whether in the test you combined sprites into a sprite sheet and what you used to generate your sprite geometry or to move it around, as without using sprite sheets you will incur a draw-call penalty on every sprite if you have them all on their own texture, as each different texture will produce a separate draw call even if Unity would otherwise do dynamic batching. In my experience Unity’s output is extremely fast and if all you’re managing is 500 sprites then you’re not optimizing properly. You should easily be able to do 10’s of thousands per frame.
Well apart from a link to a page with some stats, it wasn’t made clear that this is targetting mobile at all. We need more clarity on that. I doubt mobile can do any more sprites than you say it can… but desktop definitely can.
Inspired from this thread i made a little test today. I tested the performance of 2D Toolkit against LibGDX. Nothing special just thousands of 64x64 Sprites (with alpha) moving and rotating at the same time. Unity could handle up to 5000 Sprites at 60FPS. LibGDX however renders over 100.000 Sprites at 60FPS O.O With 200.000 Sprites i still got 30 to 40 FPS. Impressive!
Yes LibGDX is very optmized for 2D, I think with Unity you can do some things to improve the speed though. But until Unity comes out with their own 2D solution (which might be soon I think), we’ll have to use this. TBH, I don’t mind the speed decrease for now. For the ease of use that comes with unity, 5000 sprites is plenty for most games.
What is the cause of this apparent slow-down in Unity? Is it because the scripting takes up so much CPU time, whereas the XNA thing is in some kind of efficient compiled exe/dll or something? Because really if the hardware is the same Unity should be able to get the same number of sprites unless it’s doing something additional/overhead that is slowing it down.
I am agree with imaginaryhuman . We just want to know the facts…
But hey ! again Unity is 3D and its render mechanism is optimized for 3D development performance. So what ever reason is there, it doesn’t make much difference for most of the games.
You could try something like http://forum.unity3d.com/threads/147246-Futile-An-open-source-code-centric-2D-framework and see if its faster. The other solutions seems to use GameObjects for each sprite which should be slower. When I did tests maybe two years ago Gameobjects slowed unity down alot compared to using a mesh based solution. Not sure if they have been optimized since then.
Im testing it right now and it seems much faster than 2D Toolkit. But it is a pain to work with… Anyway, right now it renders 10.000 sprites at 60FPS (with more then 10.000 sprites the framerate drops significantly to 2-3 FPS; at 20.000 sprites it crashes completly). And it uses much less RAM then 2D Toolkit. But the loading times are insane. 2 mins+ (for 5000+ sprites) on my hardware is too much.
No idea why the loading times are so bad for you. About the crashing it is probable because of Unitys “A mesh may not have more than 65000 vertices.” error so you need to use more then one mesh for the sprites. If you want to test it you can use more then one layer with Futile. The limit should be closer to 16000 sprites though.
Yeah, i made a little mistake. I forgot to close the quick-start video on YouTube which puts my computer in a weird low performance mode^^ So I tested it again with your suggestions and its MUCH faster. Now I can render up to 15.000 sprites on one layer at 60FPS (loading time: 13s). But when I add a second layer with that many sprites it all goes booooom Still pretty good and probably the best option (in Unity) when that many sprites are needed. The only problem I have with futile is that it feels like I have all the disadvantages of the editor, but cant use its advantages.
