I want some advices on how to create graphical assets for mobile devices so that the game will have a good performance and not lag on mobile devices.

I had 3 issues with my games and that is they all lag after playing a little while, some lag more some less but they all lag, I think the problem is in the graphical assets. Some of the games were simple as flappy bird with a couple of images in the project but the game was lagging after playing it for a minute or two.

Now my question is, how to create graphical assets, do I need to export them on 16bit or 32bit and what is the difference, which options should I set in unity, compressed, true color, 16 bit?

And are there some other options that I can check or uncheck in unity so that the graphics will perform better on my game?

When I pack my assets in a sprite sheet, should I put them on larger sprite sheets for example 2048x2048(which is one of the options for max size in unity) or should I pack them on smaller sprite sheets?

Does a sprite sheet have to be to the power of two e.g 1024x1024 or 512x512 or I can pack my assets until they fit and the size does not matter for example the sprite sheet can be 640x410 or something like that, not on the power of two?

Does it make a difference when there is free space in a sprite sheet does that affect graphic performance or do I need to squeeze the sprites closer to each other so that there will be no empty space in the sprite sheet?

Please answer the question that I'm asking, last time I posted the same question people started asking me about the game, did I do this or that and my question then went off topic and got closed, the game is not the question, the question is everything that I mentioned above or if you have something to add that will help me.

If you can help me about this then please answer, and again please don't ask about the game and did I do this or that in the game. I hope that my question is clear, and that it is not off topic.

  • 1
    \$\begingroup\$ Your issue with lag after a certain amount of time may not be linked to your graphics. It may be an issue in your code with garbage collection, or lack thereof. \$\endgroup\$
    – Savlon
    Commented Jun 23, 2015 at 10:18
  • \$\begingroup\$ Do check the Unity manual. docs.unity3d.com/Manual/MobileOptimizationPracticalGuide.html \$\endgroup\$
    – SanSolo
    Commented Jun 23, 2015 at 10:41
  • \$\begingroup\$ Thank you all for you response, but I would still like if someone can answer the questions that I have asked. \$\endgroup\$ Commented Jun 23, 2015 at 13:30

1 Answer 1


Here are some answers to your questions: 1) If you want your sprite sheet to be compressed (which will reduce memory usage, at the cost of some quality), you will want it to be a power of two. If you are going to do completely uncompressed textures, then any size is OK. My recommendation is to stick with the power of 2, since that gives you the flexibility of using compressed textures if you want later on.

2) Free space in your sprite sheet should not affect your graphics performance, other than using up more memory than necessary. You will want to make your sprite sheets as square as possible. In your example, you have a 640x410 texture. This texture, if set to be compressed, will be scaled up to 1024x1024. You are better off modifying that texture to try and get that 640 pixel width down to 512, so that it becomes a 512x512 texture instead of a 1024x1024.

For creating assets, I would probably create them in 24 bit. If you save them in 32 bit, there will ALWAYS be an 8 bit alpha channel, and that becomes relatively expensive. Since it's a 2D game, there's probably going to be a lot of fully transparent and fully opaque pixels, with very few (if any) partially transparent pixels. My recommendation would be to create a full 24 bit image and then have a separate black and white image for your alpha. For your final format, I would then recommend 16 bit, with 5 bit color and a 1 bit alpha channel.

Overall, you will probably not see significant performance differences between different texture types unless you are graphics bound. The reason this question is difficult to answer without knowing more is that with Unity, there are many things going on simultaneously that can affect performance. Generally, your game is running each frame of the game while the last frame is being rendered. Your frame rate is going to be whichever of those takes the longest. Generally speaking, on mobile, the most expensive things you can do on the rendering side is to have alpha or expensive shaders. Anything that requires multiple passes is going to be particularly expensive. On your game side, heavy memory access and memory allocation are going to be the big performance killers. Destroying and recreating GameObjects rather than having a pool that gets re-used are the types of things that will slow your game code down (but not your rendering).

From your original description, I would agree with what other replies to your questions have said. If your graphics performance is getting worse over time, you are probably not being slowed down by the graphics (unless the graphics get consistently more complex over time). If there's a specific section that, when on camera, slows things down, then it might be rendering, but if its just getting slower over a period of time, then my first guess would be that you are creating something that is not getting destroyed, so the scene is getting busier as time progresses, which is reducing your frame rate.

More info on textures and texture sizes Unity has a few different texture types that you can set, and depending on what the setting is, as well as what is contained in the texture you are applying it to will affect what it turns into by the different settings.

TrueColor - This means that Unity is not doing anything to the color/pixel values in your texture, so they are "true". True color textures can be any width or height. If your texture has any alpha in it, this means it will create a 32 bit texture. A 32 bit texture's size is going to be width*height*4. It has a full 8 bit alpha for each pixel. If your texture doesn't have any alpha in it, it will create a 24 bit texture. A 24 bit texture's size is going to be width*height*3. It will have no alpha, and adding even a single pixel of alpha will make it convert to 32 bit, so it will become 33% bigger.

16 bit - A 16 bit texture is going to be either 2/3 the size or 1/2 the size of a true color texture, depending on whether the 32 bit texture has alpha or not. Its total size will be width*height*2. 16 bit textures can also be any size, like true color. They are smaller than true color, but at the loss of some color resolution. You will get mixed results on this setting, but they do have the advantage of supporting alpha without changing the size, and are not compressed.

Compressed - A compressed texture is significantly smaller than either a True Color or 16 bit texture. The compression will look better on some textures than others, and its beyond the scope of this explanation to give you hints on how to improve the visual quality. A compressed texture must be a power of two, and if it is not, Unity will automatically scale it up to the next largest power of two. A compressed texture is generally significantly faster to render and uses a much smaller amount of memory, and can carry an alpha channel. It tends to look best on things that are "noisy", so real pictures, or things that are busy. It tends to look worse on things that are flat colors or have sharp edges that are important. So fonts, text, and UI elements will probably have more obvious signs of compression than a texture of a tree, for example.

  • \$\begingroup\$ Thank you so much for you answer... I have more questions regarding about what you said to use the textures to the power of two, so its better for me to use the compressed mode on unity for my sprites than true color? or I am wrong? if its not to difficult for you I would like you to explain this to me, what is the difference between setting 16bit, compressed and true color and what is the best choice? and of course if you set it to be compressed you lose quality and the game looks pixalated , do you have any suggestions about that? \$\endgroup\$ Commented Jun 24, 2015 at 13:25
  • \$\begingroup\$ And also regarding the code, I did though about that because people always mention that, but I am using pooling, in fact I'm just pushing the backgrounds forward when they touch a collider in my flappy bird game and still the game gets laggy, if you are free and interested I would send you the project so that you can see for your self... I also read that for example using concatination score like "Score " + score creates a new object each time, so I'm not calling the function which sets the score in the update, Instead I'm calling a method each time the score changes... \$\endgroup\$ Commented Jun 24, 2015 at 13:27
  • \$\begingroup\$ I'm not going to look at your project, I don't have the time for it, but if you are getting significant slow down like what you are talking about, its probably something graphics related that you are creating. The comment you made about strings is correct, but I would be surprised if you notice any performance issues from it when printing a single string. Your problem will be something much more obvious. Its probably creating/destroying a bunch of tiles for some reason, or causing them to get re-initialized. \$\endgroup\$
    – Tom K
    Commented Jun 25, 2015 at 19:37
  • \$\begingroup\$ I'm going to edit my original answer to give you more info on what the different texture types are. \$\endgroup\$
    – Tom K
    Commented Jun 25, 2015 at 19:38
  • \$\begingroup\$ I'm reading your answer and I get more and more confused, because I'm not using destroy at all, I'm not even using instantiate, I'm not even deactivating game objects through code, that's why I'm confused to what is causing the problem :S I have one background that I copied like 8 times, I have a ground that I also copied 8 times, I'm only pushing them forward, I have a bird, a button and a text inside of the scene, so its a very small scene but it lags and as I said, reading what you said might be the problem gets me more confused :S \$\endgroup\$ Commented Jun 25, 2015 at 23:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .