WebP format for iOS and android

cocos2d-x C++
#1

When I’m using PVR for my textures all resources for my game size is 13.1Mb. But only works well for iOS.
I can use ETC1, but no alpha, so it’s not fit my needs, because for a typical game, like mine, I need to create sprite sheets with transparency.

So, when I used WebP, which is supported by both platforms and has alpha I got only: 6.6Mb

I just wonder, is anyone else using WebP format too?

Also, rhetorical question - why this doc abandoned - https://web.archive.org/web/20170102184332/http://www.cocos2d-x.org/wiki/Texture_Formats_Supported_by_Cocos2d-x

#2

Much of the information in the Wiki is outdated. So it was removed. Search these forums as I posted a .tar.gz of the whole wiki for anyone that still wanted to reference it.

Have you tried .pvr.ccz? It is a compressed format.

#3

I don’t see any outdated there about that formats. What exactly outdated?

So, do you think that pvr and pvr.ccz are different formats? And anyway, I said that PVR not supported by android, same that doc saying.

#4

I mean the Wiki in general was outdated, not that specific page. We should probably roll the relevant info into our docs someplace.

#5

Weird, I use on Android literally everyday.

#6

So, do you think every android has PowerVR GPU?
FYI: https://docs.unity3d.com/Manual/class-TextureImporterOverride.html (check All supported Texture compression formats).

#7

Well I have 4 Android devices and they all work. They range from being 4+ years old to brand new in November. Samsung, Vivo, HTC.

#8

And so what? Other android devices not supporting PVR, because not all of them has PowerVR GPU. Unity guys telling you that, very big guys you know… so you better to listen them).

Common, this topic was question about WebP, but not teaching you of texture formats :slight_smile: If you want, create a topic and I will answer there everything I know about textures and supported formats for platforms( if that unity documentation is not enough for you).

#9

What also very cool is that I can set 4444 in TP for WebP and even it’s not supports 4444 actually, but on the load in cocos2d-x it will be used 8888 first, but reading pixelFormat from plist - re-code it to 4444 and finally I will get RAM saving, up to 2x times compare to 8888 WebP which for example I got when pack my game with SBX.

#10

@anon98020523 You are mixing up 2 things here.

PVRTC and PVRTC2 are codecs supported by PowerVR GPUs. Which indeed might be a bad choice for Android - good for iOS.

PVR is a container format. It can put all kinds of pixel format inside - here’s a list supported by TexturePacker: 2018-03-08_18-29-56

If you want to be compatible with all platforms you can choose the RGB* formats.

If you are extremely short on memory (download size or runtime) you might prefer the hardware compressed formats.

Pvr.ccz vs pvr.gz: With pvr.ccz or pvr.gz and RGBA8888 you should get about the same as with png files.

Using 16bit colors instead (RGB565 or RGB5551 or RGB4444) you can reduce runtime memory by 50% and the download size. With dithering you should still get acceptable display quality - especially on devices with high DPI. The pvr.ccz should be better than png or webp because it really only stores 16bit pixels instead of 32bit like WebP or Png would do.

I personally would prefer quality over size and use Png or Png-8 instead of hardware compression.

16Bit vs hardware compressed: Depends on your data. Artifacts with the hardware compression might be too heavy.

WebP (lossless) vs Png: WebP might be smaller - but it depends on your image data. I don’t think that you can generally say that WebP is smaller. In terms of RAM it does not make any difference.

This is a comparison of the file formats. Always the same sprite sheet (some random sprites from Kenney.nl), 990x1559

        size    pixel     file format
-------------------------------------------
  106.972   RGBA8888      png (8 bit)   
  134.717   ETC1          pvr.gz
  135.079   ETC1          pvr.ccz
  140.935   RGBA4444	  pvr.gz
  185.908   RGBA8888	  webp (lossless)
  238.116   RGBA8888	  pvr.gz
  238.513   RGBA8888	  pvr.ccz
  293.991   RGBA8888	  png
  330.632   PVRTCII4bpp   pvr.gz (expanded to 1024x2048 because of POT constraint)
  585.555   RGBA4444	  pvr.ccz
  773.812   ETC1          pvr
6.173.692   RGBA8888      pvr

Remark: ETC1 is a bit unfair in this contest because it has to alpha channel…

What you see: Using WebP gives you good results. but there might be better options - even with good old png.

Also remember that ETC1, PVRTC,… use way less runtime memory compared to WebP.

1 Like
#11

Thats interesting, so and how it will be decoded on android with non PowerVR? Like Adreno, Mali T600 series, Adreno 400 series and so on? So, I will use PVR as Texture Format and RGBA444 as Pixel Format.

#12

It does not have to be decoded. It’s plain RGB data. Every GPU can handle this.

Only PVRTC2/4, ETC1/2, DXT1-5 require specialized hardware.

#13

I see. So, now regarding current topic question :smiley: - but with new things I can ask: what format better to use for iOS, macOS and android platforms? I definitely will use 4444 everywhere. Maybe PVR will be faster in load times? Or WebP? This also a criteria.

p.s. what is the difference between these three?

Screen%20Shot

#14

PVR is just the container uncompressed.

PVR+GZip uses gzip to compress

PVR+zlib uses zlib to compress.

@AndreasLoew?

#15

@slackmoehrle: Yes. Exactly like this.

@anon98020523: It depends all on your data and the quality you want to achieve and on your sprites.

You have a multidimensional problem here:

  • Download size
  • RAM usage
  • Render performance
  • Image quality

If you have sprites with gradients RGBA4444 with dithering might not be the best option. Gradients are a problem for the reduced color space and require heavy dithering. With high dpi displays this could work.

If you have many different colors RGBA4444 might be a good choice. You have all colors but only coarse values.
If you don’t need transparency RGBA565 is the better choice.
If you have simple transparency RGB5551 is it.

If you have a compact colors you could consider PNG-8. Might also be an option for images with more colors + dithering.

About download size: RGBA4444+dithering might be bigger than RGBA8888 because dithering increases entropy and reduces packing rates (while still requiring only 50% RAM).

Some textures deliver smaller size with ccz vs gz…
PVR and PNG32 should be about the same size - they both use the same compression algorithm.

In short: There’s no right or wrong. There’s just a best solution for your specific case. It might even be an option to pack some sheets with one method and others with another. Cocos2d can handle this - and you should not even have to change the code to try a different format.

1 Like
#16

@AndreasLoew

I mean, I’ve already tested and so it’s fits to my graphics i.e. it’s dithered very well. So one of problems is gone. Next, download size - my app only ~13Mb with WebP, so one more problem is gone too. Even with PVR it will be no more than 25Mb.

And so, I have only two choices\problems: how fast texture loads from disk on same device and render performance. So, this I probably should try by myself. Or maybe there are someone who technically know engine and can tell what will renders faster PVR or WebP. I hope I’ve set question right.

#17

It all comes down to the pixel format you use.

RGB565, RGBA4444 and RGBA5551 should be faster than RGBA8888. Simply because they only move 50% of memory. The hardware compressed formats might even be faster.

If WebP delivers the best size with your assets and you can live with the quality of RGBA4444 - that might be a good choice. TexturePacker dithers the data for you. It’s stored as RGBA8888 and cocos2d can easily convert the texture into the 16 bit format by discarding the lower bits.

#18

Yes, WebP compressed better than PVR and 4444 with proper dithering works really well for my graphics. In my tests on outputs from cocos it’s 4444(because it’s store in 8888) after cocos converts it, and as result I got same amount of used RAM when sprite sheets loaded, as for PVR.
The only difference WebP vs PVR is download size, and WebP is gives me a better compression: 15.1Mb vs 12.2Mb. Note: almost all of my game graphics are grayscale, so for colored graphics there should be more difference. So, my choice is WebP :sunny:

Also, is that new WebP 0.6.1 gives speed improvements of decoding on the device? I wanted also, test speed of decompression(loading in cocos2d-x) PVR vs WebP. How do you think, there should be some difference?

add.:
@AndreasLoew and what is the ALPHA_INTENSITY format?
It’s using same RAM as 4444 but looks exactly like 8888. I can say even more - image are the same as original. Tested on iOS&macOS - woks perfectly. Will it work on any android devices?

After all, I could probably ask everyone here again:
is anyone else using WebP format too? It’s so cool :slight_smile:

#19

ALPHA_INTENSITY is a gray scale image calculated from the sprites’ color + transparency. If your images are all gray it might look almost identical.

1 Like
#20

Just for record could you compress your resources with png 8 bits ?
e.g. https://tinypng.com
Png 8bits works the best for me. For background with gradient JPEG.