Libgdx frame FPS optimization experience

Recently, I made a game similar to the style of Plants vs. Zombies. After the game was completed, I found that the FPS was not high and the endless mode was quite a card. So I studied what caused it. At present, the optimized FPS is improved by 35%, and the effect is still satisfactory. Record your experience for sharing.

Performance Positioning]

1. reproducible DEMO

First, I wrote a demo that can reproduce the problem, and also prepared a demo that looks similar but does not have problems. This makes it easier to find problems.

2. Where is the time consumed?

When jvirtualvm is enabled for testing, it is obvious that the memory is normal, but the CPU consumption is abnormal. Repeated comparisons show that the CPU consumption is mainly in the "org. lwjgl. opengl. in the GL11.nglDrawElements method, the main time consumed for the normal demo is "org. lwjgl. opengl. GL11.glDrawElements "method. The former calls jni, and the latter calls jni directly. Therefore, there is a big gap in performance. However, at this time, it is difficult to know why the code is like this. These codes are also encapsulated and cannot see the source code.

3. Locate the code

We still need to find out which part of the problem code is. In fact, we already know that there must be something wrong with the drawing, so we can quickly find the code using the time printing method, however, the last step is an internal function call. The outer method cannot be seen at all.

4. Replacement Comparison Method

Fortunately, we have prepared two comparative demos to constantly replace different places to see what caused them. This is a stupid method, but it usually works very well, but it also has some luck. After several hours, I finally found the clues.

Performance Optimization conclusion]

1. The rendering performance is related to the number of times and the final screen area occupied by the drawing. That is to say, the performance of 100 images to cover the entire image is equivalent to that of 100 images in the same position.

2. The performance is affected only when the area of the image is large enough. The rendering work must be related to the area. However, images smaller than 25% of the screen size have almost no impact on performance, but when the image reaches 80% of the screen size, it will have a performance impact of about 40%, is not equivalent.

3. Using Linear for images consumes more performance than using Nearest. When you need to use dozens of Linear Packaging images, you need to pay attention to the performance. Use the Nearest algorithm as much as possible to improve the performance by 10%.

4. continuous use of images in the same package can greatly improve the performance (note: the performance of images in the same pack is the same as that of the two packs ). For images in the same pack, note that the performance can be greatly improved when addActor is added consecutively. Even drawing hundreds of images consecutively does not have a great impact on fps, this is why many images do not feel fps during libgdx's actor test. The optimized performance is improved by more than 100%.

5. The image is simple, and the image with more transparency has better performance. This will reduce the rendering burden. Of course, only when the image size reaches a certain level will you feel the difference, and the image complexity may be 20% different.