Making Your Game Performance Adaptated To Any Mobile Device

Making Your Game Performance Adaptated To Any Mobile Device

Introduction

Performance adaptation is essential for optimizing game performance and improving players’ gaming experience. In Cocos Creator, how to perform mobile phone performance detection and model adaptation? Developer iwae from "Shenzhen Xiaoai Smart " shared his model performance adaptation plan with us. See the source code and experience address at the end of the article. You can try it yourself at Cocos Creator | BabyShark

Let’s take a look at the performance adaptation scheme of this demo:

DemoExample

This solution supports mobile phone performance detection and mobile phone performance adaptation, providing a high-quality and smooth operation solution for high-, medium- and low-end models. During the game loading process, the program will decide the picture quality and adaptation scheme according to the GPU model and screen resolution, and other items. Players can also switch schemes in real-time in the project.

Before introducing the specific implementation method, let’s discuss it first: why do we do mobile phone performance testing?

Why do mobile phone performance testing?

As can be seen from the preview above, the picture quality of the mobile phone has an entirely different performance on the high, medium, and low settings. With the development of the mobile phone industry, the performance of mobile phones is getting higher and higher. From the Snapdragon 820 in 2016 to the Snapdragon 8Gen in 2022, the performance of mobile phones has increased by more than six times.


Source: An Antu evaluation data from 2016 and 2022

But does this mean that when playing a 3D game, we can enjoy the same quality of game?

The answer is questionable.

image

According to the latest Android device share report released by Android Studio at the end of last year, it can be seen that there is still a large user base between Android 4.0 and Android 9.0.

image

There is no doubt that our games must consider the users of high, medium, and low-end models to bring a better gaming experience to most players. Therefore, we should try our best to achieve T-shaped adaptation in terms of model adaptation: for high-end models, provide high-quality content. Mid- and low-end models must be backward compatible to ensure smooth operation.

Phone Performance Rating

So, how to make model adaptation on Cocos Creator?

First, considering the memory and performance limitations of the current mini-game platform, we abandoned real-time detection. Secondly, the test reports of most mainstream models can be obtained from the official website of GFXBench ( https://gfxbench.com ), so this time the plan is to obtain the FPS running score report of the mobile phone through the comparison method, and make corresponding adaptation plan.

The first step is to get the GPU model through pipelineSceneData.


Information within pipelineSceneData

The second step is to use the GPU information of the mobile phone and the result of the length multiplied by the width of the mobile phone resolution to compare with the GFXBench database (here, we use the third-party address https://unpkg.com/browse/detect-gpu @4.0.14/dist/benchmarks/ data cache, it is recommended to save these JSONs in your own CDN, or save the phone’s JSON information locally for parsing).

If you get the FPS score information of the mobile phone, you can obtain the performance of the mobile phone through the pre-defined adaptation level (0-4, a total of 5 levels).

If you don’t get the GPU information or the matching data samples in GFXBench, it is determined by the length and width information of the mobile phone (the accuracy rate is slightly lower). This algorithm is mainly determined based on the size of the full-screen setup of a mobile phone screen.

At this point, we have successfully obtained the performance rating of the mobile phone, and then we can optimize the high-end and low-end models according to the performance rating.

High, medium, and low-end model optimization

Cocos performance consumption is mainly in three aspects: logical overhead, physical overhead, and rendering overhead. We optimize the above 3 points according to the performance rating of the mobile phone.

By reading the engine source code (thanks to the community friend xzben for teaching me to read), we can find that when game.frameRate=30, the code layer does skip frame processing in _updateCallback, and the linear speed of the physics setting for animation and physics will have an impact. Setting frameRate=30 can effectively improve the performance of low-end computers.

private _updateCallback () {
    const director = legacyCC.director;
    let callback;
    if (!JSB && !RUNTIME_BASED && this._frameRate === 30) {
        let skip = true;
        callback = (time: number) => {
            this._intervalId = window.rAF(this._frameCB);
            skip = !skip;
            if (skip) {
                return;
            }
            director.tick(this._calculateDT(time));
        };
    } else {
        callback = (time: number) => {
            director.tick(this._calculateDT(time));
            this._intervalId = window.rAF(this._frameCB);
        };
    }
    this._frameCB = callback;
}
  • A large part of the logic overhead often comes from the consumption of update or lateUpdate, and this part of the logic can be adapted to the project.

  • In terms of physical overhead, if frameRate=30, we can multiply the linear speed of physics by 2, but for high-speed motion physical scenes, there may be cases of passing through walls.

  • In terms of rendering overhead, most rendering-related parameters can be controlled through global macro settings, including fog, shadow, shadow map size, IBL, etc.

Here are four layers of optimization for rendering overhead:

  • Video memory overhead: shadow map size, whether the skybox is enabled (if the video memory needs to be strictly controlled, the skybox needs to be dynamically loaded, which is loaded in advance in the demo).

  • Mesh rendering overhead: whether mesh LOD, shadows are turned on.

  • General rendering overhead: IBL, fog, normal material and advanced material switching, etc.

  • Particle effect overhead: particle effect culling, particle effect reduction in the number of particles.

High vs. Very High

Compare the differences in the following settings. IBL is enabled in super high-end, so models using PBR materials are affected by ambient light. Simultaneously, the shadow map size is set to 1024, and the performance of shadow details will be more delicate.

Medium vs. High

In the mid-range, the shadow is turned off, the three-dimensionality of the whole picture has dropped a lot, and the old mermaid looks more contrasting.

Low vs. Medium

The global shadow is turned off in the low-end, the water surface material is switched to the unlit material, and the God Ray of the particle effect simulation is suspended at the same time. The level and details of the picture are a little less.

LOD Mesh comparison (low-grade on the right)

In addition, LOD Mesh is set on the four sealing stone pillars behind the low-end mid-range, which reduces the number of triangles by about 55,000 compared with the mid-range, but the visual difference is not significant. The LOD here does not control the sight distance.

It is also relatively simple to create an LOD Mesh here. Copy a Mesh and compress it directly through the built-in Mesh.

In practical application scenarios, complex mesh is usually degraded by LOD according to the distance from the camera or the settings of the adaptation scheme. As shown in the tree below, the LOD cost of the lowest level is less than one-third of the highest level.

The LOD scheme is a bit more violent in the setting of the grass surface. The geometry is close by, and the patch is used for the medium shot. When it comes to the distant view, a patch is used to lie flat.

Lowest vs. Low

The lowest setting will turn off the fog effect and turn off the skybox, and picture anti-aliasing.

FAQ

Q: Why is the resolution data inaccurate on some mobile browsers?

A: Take Samsung S21 as an example, using the Adreno 660 GPU, which is not in the database. At this time, a resolution judgment is requested. When Samsung is in power-saving mode, the resolution will change to 720P. At this time, the assessment will be wrong.

Q2: The JSON data in UNPKG - detect-gpu is very large. Will it affect loading?

A: Only the corresponding GPU data will be downloaded here. For projects that require speed and a domain name (such as WeChat), these CDNs can be loaded locally. If there is no GPU, you can download BenchMark and add it to JSON.

For some projects with strict requirements on loading speed, this part of the logic can also be uploaded to the server, and the front end is only responsible for obtaining GPU and resolution information.

Q3: Why is the detected GPU information so long and not returned correctly?

A: This BenchMark information is from the external network and may not be available in a weak network environment. It is recommended to put it on your own CDN or locally.

Resource links

This program will continue to be updated and maintained.

Future plans:

  • Add deferred rendering pipeline Demo to achieve resolution modification + FXAA level adaptation;

  • LOD implementation based on camera distance;

  • Better material adaptation scheme;

  • The number of particles is adapted.

Cocos model performance adaptation solution: The BenchMark performance test has been released to the Chinese Cocos Store. You are also welcome to the forum to exchange feedback!

Download

https://store.cocos.com/app/detail/3662

Online experience address

http://www.yiyizu.com/babyshark/

Forum discussion thread

1 Like