Small knowledge, big challenge! This paper is participating in theEssentials for programmers”Creative activities

1. Texture compression format

The texture format that is not supported by the GPU must be decoded by the CPU. The GPU supports texture formats, GPU direct decoding and display, GPU decoding has a lot of optimization, random access, fast addressing and parallel decoding, so the efficiency is much higher. Also, compressed texture files are usually smaller, such as ETC1, which has a compression ratio of 8:1. Smaller files mean faster loading and less bandwidth for the system. Test how long it takes to load a 1MB file versus an 8MB file on your phone.

On ios devices, use the PVR format. DXT format on WP8 and Win8 devices. For Android devices, ETC1 format is selected for opacity mapping. For transparent maps, each of the four major GPU manufacturers has its own compression format, which can be divided into an RGB map and an alpha channel map, both in ETC1 format, and then synthesized in the game. You can also simply choose RGBA4444 format.

Measured effect: significantly improve rendering performance. The first time I played WP8 pack running on lumia 520, the comparison was stuck, the sound was stuck; After changing the texture compression format to DXT1/DXT5, it runs smoothly on the Lumia 520, and there is no sound lag.

In addition, it is recommended to make the tiles square, generally no more than 1024×1024. At first, we occasionally lost texture on Lumia 520. Later, I disassembled several 2048 tiles into 1024×1024 ones, and the problem never appeared again. The reason is not clear.

2. The limit of the frame

On mobile devices, Unity defaults to 60 frames/SEC. It is recommended to turn off vSYNC and limit FPS to 30 and 1 when entering the background. Frame limiting can significantly reduce heat and power consumption.

3. Merge atlas/Texture /Mesh

I reduced the memory footprint of the game by 30M just by optimizing the atlas. Also, because the DrawCall was reduced, rendering time was cut in half for one of the game’s more complex level list interfaces.

4. Resource optimization

Our battle scene is in 3D, and when I tested it, I found that the RENDERING of the 3D scene was very poor. When I opened the battle scene, it was around 35FPS on the Galaxy S4! The problem is that we do not have art, art is outsourced, outsourcing students do not know mobile platform optimization. I found some articles about art optimization and sent them to him, but he probably didn’t understand them either. He changed them several times, but there was no improvement in rendering performance. In the end, I was left to my own devices, unable to read the various art resources, using the stupidest dichotomy, and finally finding a Fog effect was a performance bottleneck. The effect was very weak and was turned off after consulting with the product, designers and artists. Then, phones that are much less equipped than the S4 will be able to run at 60FPS.

5. Script optimization

A lot of times, the performance bottleneck isn’t in rendering, it’s in scripting! We need to remove default methods that are empty or not needed in the script, do as little as possible in the Update, and deactive the script when it is not in use.

After the above five steps of optimization, the game has been tested on Lumia 520, iPhone 4 and Samsung 9100, and the game can reach 60FPS, meeting the launch requirements. However, since the combat scene has the most elements, the rendering is the worst, and the player spends the most time in the combat scene, I later made some optimizations for combat.

6. Unload resources and recycle garbage

Planning students feedback, when fighting, occasionally stuck. It is observed that there is a regular time lag. For loaded Assets, we automatically UnloadUnusedAssets every 30 seconds and sometimes trigger gc.collect. Unreferenced resources are now unloaded in and out of battle, and are no longer unloaded at a fixed time during battle.

7. Preload resources

Space for time. When creating a new card or effect, the frame drop is obvious. When entering the battlefield, the effect is very good.

8. Optimized battle card rendering

After the previous optimizations, I was still not satisfied, and I was always looking for further optimizations to make the combat experience better for players.

I’ve been trying to figure out how to reduce the DrawCall when we’re in combat. The 3D scene takes up more than 20 scenes, which can’t be optimized. I looked at cards. There can be up to 20 cards on the battlefield, so cards are the major contributors to DrawCall. First ask the planner if there is any content on the card that can not be displayed or merged. The planner will not give an inch. I couldn’t reduce the content, but I could render it all together so that I would only have to draw the rendered texture instead of the “scattered” content on the card.

A card has 5 or 6 drawcalls for its image, frame, race, rank, name, rank, attack/defense, etc. All of these drawcalls remain unchanged in combat except for attack/defense numbers. Apply them to a new texture, and there are only 2 drawcalls: new texture and attack/defense numbers! Ps: Attack/defense numbers can also be rendered together with other content, numbers change infrequently relative to the frame rate of the game, and redrawing each number change does not incur significant overhead.

Once you figure it out, the implementation is simple. Then, we tested wP8, ios, and Android packages on the respective devices. Test result: DrawCall reduced by half and frame count increased by twice. Moreover, the problem of fever, which had not been well solved before, was completely solved.

9. Optimization of NGUI

NGUI is inefficient in some places.

1). The animation. If there are animations, NGUI may reconstruct the DrawCall of the entire UIPanel where the animated control is located, which is expensive for the CPU. So, if you have an animated control, be sure to hang it under a SEPARATE UIPanel.

2). The anchor. UIAnchor recalculates position information every frame, so Foolish! It only needs to be calculated when initialization and window size changes (for mobile games window size does not change ^_^). \

3.) list. NGUI list (UIGrid+UIDragablePanel, ver2.6) will be very slow if there are many sub-items. For example, if you add 100 friends/have 100 cards, not only frame drop is very bad, but also very slow when dragging. According to display needs, create display number +x sub-items, cyclic reuse. Communication apps such as wechat, QQ, address book should be optimized in this way.

4.) the other. Some performance bottlenecks can be implemented in Unity native instead of using NGUI. Our main scene is a draggable strip map. At the beginning, students directly used the NGUI list to make it. Later, I found that it was a serious performance bottleneck, so I used Unity SpriteRenderer to achieve it.