Hi! I am a total newby at this sort of thing so I have been trying to do some research, but having no luck.
My problem is that I am currently developing a 2D game for android. The game is nowhere near finished and is already taking up like 25MB. It is clear that the texture imports are a problem. I have read that the best compression for Android is “RGBA Compressed ETC2 8 bits”. But when I use this, the colours are all messed up and my animations no longer make much sense due to the colour problems…
So… I researched further and I read that the resolution of the file imported must be to the power of two, i.e.:
128x128, 256x256, 512x512 etc… SO I tried this and it still looks awful.
Now I could go on continuing to make my game, but the file size will get huge, and one day I may wish to release it… so I have put development on halt due to the problems I may have in the future.
I am probably doing something stupid but I really am clueless when it comes to importing/exporting, compression, resolution etc.
Any help would be greatly appreciated.
There are a number of pitfalls with texture compression, but it’s possible to work around them in different ways.
Compression uses a lower colour space, for example RGB565 or RGBA5551 (or even a different order, but the result is the same). This means you have slightly more range in the green space, and more limited reds and blues. The way to make this look as good as possible is to use dithering. You squeeze the colours in your sprites to fit in a smaller colourspace while looking visually the same to most humans. Floyd-Steinberg dithering is the go-to method here, and hopefully that’s found in your image editor.
In a pinch, you can use a dithering option in a program like Texture Packer. I had some lovely high-colour sprites with gradients that plain texture compression absolutely destroyed. Using TP’s dithering I got results which looked exactly the same on mobile devices with RGBA4444 16-bit images as the source images at 32 bits. Gradients are the bane of colourspace compression, so dithering is basically required.
Sometimes you might also have colours bleeding over from one sprite to another. In fact, some forms of compression may take the edge colours from one sprite, get really confused, and apply entirely wrong colours in the middle of another sprite not even bordering on it. I’ve seen weird results like that many times, and the only way to avoid it is by using one or two fully transparent pixels wide borders around the sprites. This slightly increases image sizes and can play havoc on your carefully packed sprites, but file compression optimises it away for storage at least.
Note that there are three different things considered compression in this context:
1.Reducing 24/32-bit colours to 16-bit RGB/RGBA. This is the most destructive variant.
2.File compression (gzip etc.), which returns exactly what it got in with decompression.
3.JPEG-style block optimisation. Typical sequences of 4 pixels may be optimised down to shorter reference bytes. This varies per compression method, and can gain even more after file compression is applied. This usually isn’t destructive, as it just uses a table of shorthand for squares of pixels.
In case of the example you show, you could also make a sprite sheet of only the part that actually changes and only have the big block once. Then put it together with 2 separate sprites
