- Home /
Best Image Formats, Sizes, and Resolutions for Unity Sprites?
Hello,
I've been wondering what is the best image format, size, and resolution to use with unity for a 2D game. I've been building my 2D game for a while now, unfortunately though, the game reached a size of 150MB (for Android) and its not currently running on old phones with low processing or memory.
Since it is a 2D game, I figured that reducing the size of the game is the best thing to do whether it is the cause of the problem or not.
Currently, I design all my sprites with 1000x1000 pixels, and with 150 pixels per centimeter.
A sub-question: Why does a 60KB png image with alpha (with the above size and resolution) becomes a around 5MB in Unity?
Thanks in advance.
So, assu$$anonymous$$g an HD screen with resolution 1920 x 1080, the size all your sprites (1000x1000) would be over half screen width, by one screen height? This is what you actually want/need? That's a lot of overlap...
Just trying to understand what you need...
Hi @pako, and thanks for the reply. Actually the dimensions of the sprits have nothing to do with the screen size. I just made them like this to insure that I have the best quality possible. Are trying to say that I should make them based on the actual size? because I export it with that size, and then resize it in unity to fit my liking.
Also, what do you mean by overlap?
Answer by NorthStar79 · Dec 26, 2017 at 01:21 PM
first, resize all your sprites to power of two (POT) [like 1024x1024 - 1024x512 - 2048x2048], this allows unity to compress your sprites very efficiently, also chec alpha to none if you dont use alpha channel (this is important) here :
also, you can increase compression too.
Hello @NorthStar79 and thank you for your answer, is 1000x1000 considered as a POT? because I have above 100 sprites in my scene right now and I'd hate resizing all of them unless necessary.
no, only 2-4-8-16-32-64-128-256-512-1024-2048 and 4096 is considered as POT. you can use this option at import settings but it may deform your sprites.
but i must say that. if you use ToNearest, there will be only 24 pixel wide deformation. that may be acceptable for your project, check it out. but dont forget to backup your project before.
Oh, please excuse my question, I confused Power of Two with Divided by Two. $$anonymous$$y apologies.
Now that I got my hands on my PC, I opened unity and went through all the settings that you suggested. By changing the image's width and height to 1024x1024, ETC2 Compression was enabled, and the size went from almost 6$$anonymous$$B to 1$$anonymous$$B.
The reduction of 5$$anonymous$$B just by changing an image could drastically reduce the game's size.
Thank you very much for taking the time to answer my question.
Answer by pako · Dec 26, 2017 at 04:27 PM
Well, the way you do it, you end up with unnecessarily big textures.
Overlap would be applicable, if you actually needed the textures to be 1000x1000, but you don't. But if you did... this is what would happen: assuming a target HD screen with resolution 1920 x 1080, you have 1920 pixels in width. So, if each texture is 1000 pixels wide, with 2 sprites arranged side by side you'd have 2000 pixels to fit into the 1920 pixels of the screen width, so the minimum overlap would be 80 pixels. Now, if you have more than 2 sprites, or your 2 sprites are not placed as far apart as possible, the "excess" pixels (overlap) would be much greater than the 80 pixels.
Anyway, I just mentioned overlap to emphasize a point.
The thing is, that you should have at least one target screen resolution. Personally, I have two, a. 1920x1080 for high end devices, and b. half of that 960x540 for low end devices. Then, I provide each texture for the sprites, at a size suitable for each screen resolution 'a' and 'b'. At start up of the game, I detect if the device is high or low end, and load the sprites suitable for the particular screen resolution. Of course, in a simpler setup, you can provide textures for the higher resolution only, and scale down for any lower resolution.
I think it's best to use an example to demonstrate (using the above 2 target resolutions). This is the workflow I have found works well for me:
Say I want to work out how large a texture I need for my "Player" sprite. First of all, I want to find out the percentage of the screen width and height that my Player occupies. So, I set the Game view to display at Landscape 1920x1080, as my game. Then, I just take a ruler and measure the game screen width and height, and the Player's width and height. Of course, to do that, I use an existing spite for the player, at a suitable scale, or another sprite in the scene that would help me determine the size of the Player sprite by comparison.
So, lets say: game screen width and height: 30.7 cm x 17.3 cm (approximately). Player's width and height: 2.5 cm x 3.2 cm (approximately).
This gives the Player to be: width 2.5 / 30.7 = 0.081 of the screen width, which is 1920 pixels, i.e Player width in pixels is: 0.081 x 1920 = 156 pixels.
Similarly, the Player to be: height 3.2 / 17.3 = 0.185 of the screen width, which is 1080 pixels, i.e Player height in pixels is: 0.185 x 1080 = 200 pixels.
So, the texture size I need for my Player sprites is 156x200 pixels, to display in the best quality possible at the target screen resolution of 1920x1080 pixels.
if I supply a texture of 1000x1000 pixels for the same sprite, it would be 1000/156 = 6.4 times larger than necessary in width, and 1000/200 = 5 times larger than necessary in height. So, the texture size would be over 30 times larger than what's needed with no gain at all in quality at the target screen resolution.
Of course, it's a very crude method to get the ruler out and measure the screen, but it has worked fine for me so far. If someone can suggest a better, "more elegant" method, please let me know. I'd be happy to try it out.
Regarding "Power of Two" for best compression. Well, I just don't use compression, because whenever I did, I noticed significant degradation of quality. This is an old thing, and maybe things have improved, but everything works fine for me with no compression.
Regarding your sub-question. It's kind of a mystery to my how Unity texture importer handles images. I've been surprised over and over for many years, and I still haven't found "the formula" used. I believe that what's happening is that a 60KB png has compression applied, but I suspect that there's enough information in the png so that Unity importer can decompress it to 5MB, so that later it can compress it according to your custom settings. Anyway, this is just speculation. If someone knows exactly what's happening, I'd be grateful to know too.
Wow, I love your answer. It is very detailed and it covers some good points. What you said makes a lot of sense. I will be sure to keep these points in $$anonymous$$d in my future projects. As for now, I want to make as $$anonymous$$imal changes as possible as I have more than 100 sprites in my game at the moment.
If I could accept more than one answer, I would definitely accept yours. However, I can upvote your answer and reward you for the detailed explanation.
Again, thank you for the very detailed answer.
Thank you so much. It explains a lot that why some sprites are not displayed properly in low-end mobile after the build.