Unity optimization Summary

Our games have been launched on the wp8, ios, and android platforms. This is my first Unity project. I encountered a lot of difficulties and setbacks during this period, but I am exploring with my friends all the way. Now, the game has been online for a while and is stable. For Unity, I have been studying in projects. I will write a series of articles to record my own learning and hope to see a lot of friends in the articles.

In the middle and late stages of the project, I made some optimizations. Here I will record and summarize them.

I. Texture compression format

CPU decoding is required for non-GPU-supported texture formats. GPU-supported texture formats are directly decoded and displayed by GPUs, and GPU decoding is greatly optimized, random Access, fast addressing, and parallel decoding are much more efficient. In addition, the compressed texture file is usually smaller. For example, if the ETC1 compression ratio is, a small file size means faster loading and saves system bandwidth. Compare and test the loading time of a 1 MB file and an 8 Mb file on your mobile phone.

On ios devices, we recommend that you select the PVR format. DXT format on wp8 and win8 devices. For android devices, opacity pasters are generally supported in the ETC format. for transparent pasters, four GPU manufacturers have their own compression formats. You can select rgba16.

Actual Effect: significantly improves rendering performance. My first wp8 package was run on lumia 520. The comparison was slow and the sound was choppy. After the texture compression format was changed to DXT1/DXT5, it was smooth on lumia 520, the sound gets stuck.

In addition, it is recommended to make the texture square, generally not more than 1024x1024. We occasionally lost textures on lumia 520 at first, and then I split several 2048 textures into X. The problem never happened again. I didn't understand the cause, if you know your friends, please do not give me any further information.

2. Frame Restriction

On mobile devices, the default value of Unity is 60 frames per second. We recommend that you disable vertical synchronization, set FPS to 30, and set it to 1 when you enter the background. Frame limiting can significantly reduce fever and power consumption.

3. Gallery/material/Mesh merge

I reduced the memory usage of the game by 30 mb by optimizing the gallery. In addition, because DrawCall is reduced, rendering time is reduced by half in a complicated level list interface in the game.

4. Resource Optimization

Our combat scenario is 3D. During my test, we found that the rendering performance of this 3D scenario was poor. When we opened the combat scenario, there was only about 35 FPS on Galaxy S4! What's terrible is that we don't have any art, and art is outsourced. The outsourcing staff don't know how to optimize the mobile platform. I found some articles about art optimization and sent them to him. I guess he didn't understand it either. He changed it several times and the rendering performance was not improved. In the end, I had to go into battle on my own. I couldn't understand the various types of art resources. I used the dumbest binary method. Finally, I found that the performance bottleneck was caused by a splash of water and smoke. The performance of this effect is very weak. After discussing with products, planning, and art, the effect is closed. Then, mobile phones that run more than S4 can run at 60 FPS.

5. Script Optimization

In many cases, the performance bottleneck is not rendering, but script code! We need to delete the default method that is null or not needed in the script. do as little as possible in the Update, and deactive the method when the script is not used.

After the optimization in the above five steps, the game can reach 60 FPS In the lumia 520, iphone 4, and Samsung 9100 tests, meeting the online demand. However, since the most elements are involved in the combat scene, rendering is the worst performing, and players have the longest time in the combat scene, I have made some optimizations later on the combat scene.

6. Resource uninstallation and garbage collection

The planners reported that during the battle, the program occasionally gets stuck. After careful observation, we found that there was a regular timing lag, and then we checked the code and found that, out of memory optimization considerations, terender designed to automatically uninstall resources every 30 seconds, resource uninstallation sometimes triggers GC. collect (). Instead of detaching resources when entering or playing the game, this solves the occasional choppy problem.

7. Resource pre-loading

Change the time by space. When entering the battlefield, pre-load combat effects and cards to reduce the number of frames when loading cards and launching skills. In this place, I first wrote a blocking style, and later found that it would affect the player's experience in entering the battlefield. Instead, I changed it to non-blocking and loaded it one by one using coroutine.

8. Optimized combat card Rendering

After the optimization above, I still don't want to satisfy myself. I have been seeking for continuous optimization, so that the player's combat experience can be better.

We can reach about 120 DrawCall calls during the battle. I have been thinking about how to reduce DrawCall, and more than 20 3D scenes are occupied, this item cannot be optimized (no art Ah % >_<% ). I stare at cards, and there can be up to 20 cards on the battlefield. Therefore, cards are the "major contributor" of DrawCall ". First, ask the planning staff if there is any content on the card that can be left blank or merged. I had to come back and think about it. I finally thought that I could not reduce the content displayed, but I could render all the content together, in this way, you only need to draw the rendered texture instead of the "scattered" contents on the card.

Card pictures, frame, race, level, name, level, attack/defense, etc., contribute 5 or 6 drawcalls. In addition to attacking/defending numbers, other content will not change during the battle, rendering them to a texture, and DrawCall will only have two: rendered texture and attack/Defense numbers! Ps: Later I thought that attacking/preventing numbers could also be rendered together with other content. The number changes were not frequent compared to the frame rate of the game, every time the number changes, re-drawing does not bring significant overhead.

After understanding, the implementation is very simple. Then, I prepared the wp8, ios, and android packages separately. I was excited to test each platform for at least 30 minutes. The test result is: DrawCall is halved, and the number of frames is doubled. Moreover, the hot issue that has not been well solved before is completely solved. Playing on the battlefield for more than 30 minutes, lumia 520, Galaxy S4 and iPhone 4s were slightly warm, and iPod Touch5 was completely cool. Compared to the currently popular legend of the turret, the victory is-D.

Before optimization, there were 12 cards on the game, 14 cards on the game after the FPS 112.7 optimization, and FPS 208.6
DrawCall 70, Tris 2.1 k, Verts 3.7 k DrawCall 47, Tris 1.4 k, Verts 2.3 k

From the above comparison, we can see that although there are more cards after rendering optimization, FPS is improved by nearly doubled, and the optimization effect is very good. The more cards, the more significant the optimization effect will be.

The above are some of the Unity optimization solutions that I found out suitable for our games when working on our projects. Because our game is 2D, it may be optimized for 3D games. Some solutions may not be applicable or comprehensive enough. At present, we are not doing well in some places. optimization is a long-term and continuous task, and I will continue to do so later.

Next Article Notice: The Unity automatic packaging tool can package dozens of channels/platforms in one click.