Go to iOS and Android game texture optimization and memory optimization (COCOS2D-X)

iOS and Android game texture optimization and memory optimization (COCOS2D-X)

(not completed)

1, 2d game the most memory is undoubtedly the picture resources.

2, Cocos2d-x different platform to read the texture of different mechanisms. Under iOS using Cgimage,android and Windows is directly calling the PNG library. I tested, using the PNG library directly read PNG will save about 1MB more memory than cgimage (image occupies 4mb of memory) but the speed is one times slower than Cgimage. How time and space can be a choice depends on the actual situation. But the best option seems to be PVR (even if the Android version does not use PVRTC4).

3, in general, we can directly use the W * H * bpp to get a texture of the memory, such as a 1024*1024 format for argb8888, then he accounted for the memory is 1024*1024*4=4MB. Before seeing a blog that mentions JPG will open up 3 times times with this memory (converted to PNG first and then parse PNG), but the new iOS system does not seem to have this problem. JPG consumes almost the same amount of memory as PNG, and JPG parsing is faster (almost all 4MB parsing +4MB texture data, and JPG parsing time is half of PNG), but it's weird because JPG is no transparent color, a pixel up to 3 bytes, and png a pixel of 4 bytes, JPG textures should take up less memory, and later looked at the next cocos2d iOS loaded image code, which transforms all textures into rgba8888 format, so both JPG and PNG occupy 4 bytes. Because cocos2d support for other textures is not good enough, PVR will appear so efficient.

4, the PVR format can be recognized by the video card, and do not need to open up temporary memory to read, so even if the same as the argb8888 format of the picture, PVR will be more efficient than PNG, although it will not save the program stable running memory, but will avoid loading a large number of images when the memory spikes. And if it is an iOS device, you can use the PVRTC4 format image, which is equivalent to the DDS image under Windows, can be directly supported by the graphics card. It is lossy compression, a pixel only 4 bits, but if there is no gradient translucent color, the general effect is acceptable, and its savings in memory and CPU time is very significant.

5, PVR is not a balm. Although the PVR format can be used under Android devices, it is not possible to use PVRTC4, and it is not feasible to really reduce the memory of the game via PVR like on iOS devices.

6, Pvr.ccz is actually the PVR Picture Zip packaging, the program read the time or first extract the PVR resources, and then read the PVR. However, due to the compression can greatly reduce the volume of the picture, so although more understanding of the pressure process will not have a particularly large CPU consumption.

7, a JPG picture of the actual load process memory consumption, with a 1024*1024 argb8888 500k jpg Image for example: A. Read picture file (memory consumption, 500k) B, parse jpg data (cgimage, 4MB) C,      Release 500k of image memory D, OpenGL texture data (4MB) e, release cgimage 4MB of memory.  Note that this process is not necessarily sequential execution, freeing cgimage memory is actually a system-determined, and will be quick, but not necessarily immediate. So the memory will instantly soar around 9MB, then reduce 5MB, stabilize to about 4MB

The PNG picture is loaded with this same

PVR pictures can save the consumption of parsing the image data to the texture step. That is to read the PVR picture resources (equivalent to decompression PVR.CCZ to memory, if it is 1024*1024 argb8888 format, then the image size is 4mb,ccz compressed image around 1MB) consumption 4mb, the PVR picture data submitted to the graphics card consumption 4mb. Then release the file data 4mb. This seems to be not very advantageous compared to PNG's memory footprint. (Note that the PVR in this case refers to the argb8888 of the PVR package, which is vastly different from the performance of PVRTC4)

8, because the final consumption of memory are texture data, so long as the texture data format is certain, no matter what the format of the image is the same memory consumption. For example, using the PNG8 image, the volume will be reduced by 70%, but the memory consumption and PNG24/PNG32 is equivalent (when reading the palette will be restored to True color, that is, although the PNG8 is a pixel only 8 bits, but read into memory when the palette color will be restored, Still need to open up 1024*1024*4 bytes of space to store texture data). Of course there is no transparent color, cocos2d treatment or there is a difference. If there is no transparent color, you can use the PNG24, then the required texture space is 3MB.

Here is also a point to explain, generally we deal with the DDS texture under windows, we are accustomed to it by 2 of the whole power to it, although the picture content only 900*900, but the picture size is 1024*1024. The memory we use to read this image is 4MB, and a power of 2 will help improve the efficiency of the operation, but it is not very necessary. Both iOS and Android devices support textures that are not 2 full power. So if it's a PNG picture, then how big it is. The memory consumed at this time is only 900*900*4=3MB.

9, do not be too superstitious so-called removal of the alpha channel to save memory.  This will also be a practical analysis of the specific results. I tested (using Cocos2d-x and the Wisp 3d engine respectively), and PNG images in rgba8888 and rgb888 format showed the same amount of memory consumed. 24-bit image Although the memory opened up when reading is only 3MB (1024*1024*3, note that if it is read with cgimage, that value is 4MB), but Glteximage2d submitted to the video card will still increase 4MB of memory. may be related to the data alignment of the video card.

Here I test there is a strange place, if the Npot picture with PVR, rgb888 than rgba8888 consumes less memory, but pot picture both are the same (PNG image two cases are the same). It is possible that the PowerVR graphics card has special handling.

10, rgb565 and rgb5551 's picture consumes the memory is half of rgba8888, if does not have the transparent gradient, the visual also does not see what difference. Some large background graphs can be preferred in this format.

11, PVR pictures load faster than PNG and JPG (same 1024*1024 argb8888), PNG consumption time may be about 700ms, but PVR only needs about 100ms. If it is PVR.CCZ compression, the time consumed is about 200ms. It is obvious that PVR has a great advantage in loading speed. This should be because PNG and JPG need to restore the image data to Rgba, but PVR can pass the image data directly to the graphics card. PVRTC4 images can be directly supported by the PowerVR graphics card.

Summary below:

1, the final decision to occupy the memory of the image is its pixel format and size, regardless of its extension. Png8 png32 jpg PVR as long as its pixel format is argb8888, then the final image occupies the same memory.

2, if not PVRTC4 format, then do not expand to 2 of the whole power, because the smaller the picture, the smaller the memory consumption

3, the removal of transparent channel alone will not reduce the memory consumed by the image, PNG and JPG images can not reduce the volume of the picture, so the rgb888 format is not recommended. Alternative options for rgb565 and rgb5551.

5, carefully load the image when the temporary opening of the texture data caused by high memory, you can consider to join the memory pool, timely opening up and release buffer.

6, if is to reduce the picture volume can choose: 1, the jpg--compression ratio is highest, the quality is good, but does not support translucent 2, png8--the same picture will be slightly larger than the JPG, uses the Imagealpha to convert, the visual almost does not see the difference. Both of these image formats can greatly reduce the volume of pictures (reducing 70%~80%), but do not help to reduce memory

7, if it is to reduce the memory can choose: 1, no transparent color picture unified conversion to rgb565 format, this time can not use PNG8, so png and PVR.CCZ picture size is almost the same, PVR.CCZ faster, so recommended PVR.CCZ rgb565 format 2, If the transparent color is just a key color callout, without a gradient blend, then the PVR.CCZ format of the recommended rgb5551 (R5_A1)

8, you can consider writing a packaging system, unified resource file packaging, rather than a single file with Pvr.ccz Zip compression, so that you can achieve higher efficiency. (for example, I encapsulated a blizzard of MPQ packaging, its reading speed and local file read speed, so that the best read efficiency)

Finally attached my test data log, the picture is a 1024*1024 picture, the actual picture content size is 960*700. Test device iphone4,png jpg and other picture loading code modified to Windows version. The back of Tex is the load time of the picture. The brackets behind the over are the memory consumed by the image loading.

2012-12-27 14:28:54.614 hellocpp[4939:707] cocos2d:surface size:960x640cocos2d:cocos2d: Cocos2d-2.1beta3-x-2.1.0cocos2d:cocos2d:gl_vendor:imagination TechnologiesCocos2d:cocos2d:GL_RENDERER:PowerVR SGX 535cocos2d:cocos2d:gl_version:opengl ES 2.0 imgsgx535-63.24cocos2d:cocos2d:gl_max_texture_size:2048cocos2d:c OCOS2D:GL_MAX_TEXTURE_UNITS:8COCOS2D:COCOS2D:GL supports PVRTC:YESCocos2d:cocos2d:GL supports BGRA8888 Textures:no  Cocos2d:cocos2d:GL supports Npot Textures:YESCocos2d:cocos2d:GL supports Discard_framebuffer:YESCocos2d:cocos2d:GL   Supports shareable VAO:YESCocos2d:cocos2d:compiled with Profiling Support:notex 195 MAP_001_BG.PVRMAP_001_BG.PVR  ---over PROESS:11.0MB (4.0MB) Free:274.6mbtex 159 MAP_001_BG_RGB.PVRMAP_001_BG_RGB.PVR---over PROESS:15.0MB    (4.0MB) Free:270.6mbtex 711 map_001_BG.jpgmap_001_BG.jpg---over PROESS:19.1MB (4.1MB) Free:266.7mbtex 653 Map_001_BG_rgb.jpgmap_001_BG_rgb.jpg---over ProESS:23.1MB (4.0MB) Free:262.6mbtex 670 map_001_BG.pngmap_001_BG.png---over PROESS:27.1MB (4.1MB) FREE:258.7MBT Ex 739 map_001_BG_rgb.pngmap_001_BG_rgb.png---over PROESS:31.1MB (4.0MB) Free:254.3mbtex MAP_001_BG.PV R.CCZMAP_001_BG.PVR.CCZ---over PROESS:35.1MB (4.0MB) Free:250.4mbtex 204 MAP_001_BG_RGB.PVR.CCZMAP_001_BG_RGB.P VR.CCZ---over PROESS:39.2MB (4.0MB) Free:246.5mbtex-MAP_001_BG_RGB565.PVRMAP_001_BG_RGB565.PVR---over PR    OESS:41.2MB (2.0MB) Free:244.6mbtex 710 map_001_BG_rgb565.pngmap_001_BG_rgb565.png---over PROESS:45.2MB (4.0MB) Free:241.1mbtex 591 map_001_BG_rgba8888f.pngmap_001_BG_rgba8888f.png---over PROESS:47.8MB (2.6MB) free:238.3    Mbtex 484 map_001_BG_rgba8888f.jpgmap_001_BG_rgba8888f.jpg---over PROESS:49.7MB (1.9MB) Free:236.5mbtex 123 MAP_001_BG_RGBA8888F.PVRMAP_001_BG_RGBA8888F.PVR---over PROESS:52.4MB (2.7MB) Free:234.1mbtex 589 map_001_bg_ Rgb888f.pngmap_001_bg_rgB888f.png---over PROESS:55.1MB (2.7MB) Free:231.2mbtex 478 map_001_BG_rgb888f.jpgmap_001_BG_rgb888f.jpg---ove R PROESS:57.0MB (1.9MB) Free:229.4mbtex MAP_001_BG_RGB888F.PVRMAP_001_BG_RGB888F.PVR---over PROESS:59.0MB  (2.0MB) FREE:227.8MB (LLDB)

The second log is the iOS version of the picture loaded, the other same as the previous, you can see faster than the Windows version of the PNG load faster, but the memory consumption is higher

2012-12-27 15:36:10.330 hellocpp[4979:707] cocos2d:surface size:960x640cocos2d:cocos2d: Cocos2d-2.1beta3-x-2.1.0cocos2d:cocos2d:gl_vendor:imagination TechnologiesCocos2d:cocos2d:GL_RENDERER:PowerVR SGX 535cocos2d:cocos2d:gl_version:opengl ES 2.0 imgsgx535-63.24cocos2d:cocos2d:gl_max_texture_size:2048cocos2d:c OCOS2D:GL_MAX_TEXTURE_UNITS:8COCOS2D:COCOS2D:GL supports PVRTC:YESCocos2d:cocos2d:GL supports BGRA8888 Textures:no  Cocos2d:cocos2d:GL supports Npot Textures:YESCocos2d:cocos2d:GL supports Discard_framebuffer:YESCocos2d:cocos2d:GL   Supports shareable VAO:YESCocos2d:cocos2d:compiled with Profiling Support:notex 196 MAP_001_BG.PVRMAP_001_BG.PVR  ---over PROESS:11.0MB (4.0MB) Free:275.8mbtex MAP_001_BG_RGB.PVRMAP_001_BG_RGB.PVR---over PROESS:15.0MB    (4.0MB) Free:271.9mbtex map_001_BG.jpgmap_001_BG.jpg---over PROESS:19.3MB (4.3MB) Free:267.6mbtex 151 Map_001_BG_rgb.jpgmap_001_BG_rgb.jpg---over ProESS:23.5MB (4.2MB) Free:263.8mbtex 344 map_001_BG.pngmap_001_BG.png---over PROESS:28.7MB (5.3MB) FREE:258.7MBT Ex 328 map_001_BG_rgb.pngmap_001_BG_rgb.png---over PROESS:34.0MB (5.3MB) Free:253.6mbtex 237 MAP_001_BG.PV R.CCZMAP_001_BG.PVR.CCZ---over PROESS:38.0MB (4.0MB) Free:249.6mbtex 221 MAP_001_BG_RGB.PVR.CCZMAP_001_BG_RGB.P VR.CCZ---over PROESS:42.0MB (4.0MB) Free:245.2mbtex 98 MAP_001_BG_RGB565.PVRMAP_001_BG_RGB565.PVR---over PR    OESS:44.0MB (2.0MB) Free:243.2mbtex map_001_BG_rgb565.pngmap_001_BG_rgb565.png---over PROESS:48.9MB (4.9MB) Free:238.2mbtex 293 map_001_BG_rgba8888f.pngmap_001_BG_rgba8888f.png---over PROESS:52.8MB (3.9MB) free:234.2    Mbtex map_001_BG_rgba8888f.jpgmap_001_BG_rgba8888f.jpg---over PROESS:55.7MB (2.9MB) Free:231.7mbtex 143 MAP_001_BG_RGBA8888F.PVRMAP_001_BG_RGBA8888F.PVR---over PROESS:58.3MB (2.7MB) Free:228.8mbtex Map_001_bg_r Gb888f.pngmap_001_bg_rgb888f.png---over PROESS:62.2MB (3.9MB) Free:225.3mbtex map_001_BG_rgb888f.jpgmap_001_BG_rgb888f.jpg--- PROESS:65.1MB (2.9MB) Free:222.7mbtex MAP_001_BG_RGB888F.PVRMAP_001_BG_RGB888F.PVR---over PROESS:67.0MB (1  .9mb) FREE:220.7MB (LLDB)