Interpretation of CocosCreator source code: engine startup and main loop

Preface

preparation

I wonder if you have ever thought about this: if the game world is compared to a car, then how does this "car" start and how does it keep running?

As the title says, the content of this article is mainly about the startup process and main loop of the Cocos Creator engine.

The main loop also involves: component life cycle and timer, easing system, animation system and physics system, etc.

This article will explain the relationship between the main loop and each module at a macro level. It will also briefly introduce each module, but will not go into the specific implementation of the module.

Because if I "touch" every module, I'm afraid I won't be able to finish this article.

Go!

I hope that after reading this article, you will have a better understanding of the Cocos Creator engine.

At the same time, I also hope that this article can play the role of "a master leading you into the door", let's work hard together to practice~

In addition, the "Source Code Interpretation" series (should) continue to be updated. If you want Pipi to interpret a module of the interpretation engine, you are also welcome to leave a message to tell me, I... I will consider it hahaha~

This article uses Cocos Creator 2.4.3 as a reference.

text

Start the process

index.html

For the Web platform the index.html file is the absolute starting point.

In the default index.html file, the layout of the game startup page is defined, the main.js file is loaded, and there is also a piece of code that is executed immediately.

Here is a part of the key code in the file:

// Load the engine script loadScript(debug ? 'cocos2d-js.js' : 'cocos2d-js-min.ec334.js', function () {
    // Is the physics system enabled?
    if (CC_PHYSICS_BUILTIN || CC_PHYSICS_CANNON) {
        // Load the physics system script and start the engine loadScript(debug ? 'physics.js' : 'physics-min.js', window.boot);
    } else {
        // Start the engine window.boot();
    }
});

The above code is mainly used to load the engine script and the physical system script. After the script is loaded, the window.boot() function defined in main.js will be called.

💡 For native platforms, the main.js file will be loaded in applicationDidFinishLaunching() function of {項目目錄}build\jsb-link\frameworks\runtime-src\Classes\AppDelegate.cpp file. (Thanks to Please Allow Me to Sleep for the supplement)

🧵 Code minification

The word -min in the script file name generally means that the code in this file is compressed.

Compressing code can save the space occupied by code files, speed up file loading, and reduce traffic consumption, but it also makes the code less readable and not conducive to debugging.

Therefore, after turning on the debug mode, the uncompressed code file will be used directly, which is convenient for development debugging and error positioning.

main.js

window.boot()

There are also some differences in the content of main.js for different platforms. Here we ignore the differences and only focus on the key common behaviors.

The content of the main.js file basically defines window.boot() function.

💡 For non-web platforms, the window.boot() function will be called directly after the definition, so main.js is their starting point.

window.boot() function has the following key behaviors:

1. Define the onStart callback function: mainly used to load the startup scene
2. cc.assetManager.init(...) : Initialize AssetManager
3. cc.assetManager.loadScript(...) : load the plugin script in the src directory
4. cc.assetManager.loadBundle(...) : loads the bundle in the project
5. cc.game.run(...) : Start the engine

I won’t post the code for this part. You can take a look at the main.js file after building your project.

cc.game

The cc.game object is an instance of cc.Game class. cc.game contains the main game information and is responsible for driving the game.

In layman's terms, the cc.game object is the module that manages the engine life cycle. It is required for operations such as starting, pausing, and restarting.

CCGame.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCGame.js

run()

cc.game.run() function specifies the engine configuration and onStart callback and triggers cc.game.prepare() function.

run: function (config, onStart) {
    //Specify engine configuration this._initConfig(config);
    this.onStart = onStart;
    this.prepare(game.onStart && game.onStart.bind(game));
}

Portal: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCGame.js#L491

prepare()

cc.game.prepare() function mainly compiles the project code quickly and calls _prepareFinished() function when the project is previewed.

prepare(cb) {
    // Skip if already prepared if (this._prepared) {
        if (cb) cb();
        return;
    }
    // Load preview project code this._loadPreviewScript(() => {
        this._prepareFinished(cb);
    });
}

Portal: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCGame.js#L472

For details on quick compilation, you can open the browser's developer tools when previewing the project, search (Ctrl + P) __quick_compile_project__ in the Sources column to find __quick_compile_project__.js file.

_prepareFinished()

The main functions of cc.game._prepareFinished() function are to initialize the engine, set the frame rate timer, and initialize built-in resources (effect resources and material resources).

When the built-in resources are loaded, cc.game._runMainLoop() will be called to start the engine main loop.

_prepareFinished(cb) {
    // Initialize the engine this._initEngine();
    // Set the frame rate timer this._setAnimFrame();
    // Initialize built-in resources (load built-in effect and material resources)
    cc.assetManager.builtins.init(() => {
        // Print the engine version to the console console.log('Cocos Creator v' + cc.ENGINE_VERSION);
        this._prepared = true;
        // Start mainLoop
        this._runMainLoop();
        // Emit the 'game_inited' event (i.e. the engine has been initialized)
        this.emit(this.EVENT_GAME_INITED);
        // Call the onStart function defined in main.js if (cb) cb();
    });
}

Portal: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCGame.js#L387

💡 It is important to mention the _setAnimFrame() function called in _prepareFinished() .

_setAnimFrame()

cc.game._setAnimFrame() internally adapts to different game frame rates.

In addition, window.requestAnimationFrame() interface is encapsulated for compatibility with different browser environments. We will talk about the details below.

I won’t post the code of _setAnimFrame() here, but you can check it out if you need it.

Portal: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCGame.js#L564

_runMainLoop()

The name of cc.game._runMainLoop() function is very simple and direct. It is used to run mainLoop() function.

Let's take a look at the code:

_runMainLoop: function () {
    if (CC_EDITOR) return;
    if (!this._prepared) return;
    // Define local variables var self = this, callback, config = self.config,
        director = cc.director,
        skip = true, frameRate = config.frameRate;
    // Show or hide performance statistics debug.setDisplayStats(config.showFPS);
    // Set frame callback callback = function (now) {
        if (!self._paused) {
            // Loop call callback self._intervalId = window.requestAnimFrame(callback);
            if (!CC_JSB && !CC_RUNTIME && frameRate === 30) {
                if (skip = !skip) return;
            }
            //Call mainLoop
            director.mainLoop(now);
        }
    };
    // Will start looping callback in the next frame self._intervalId = window.requestAnimFrame(callback);
    self._paused = false;
}

Portal: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCGame.js#L612

From the above code, we can know that _runMainLoop() mainly uses window.requestAnimFrame() interface to implement the loop call of mainLoop() function.

window.requestAnimFrame()

window.requestAnimFrame() is the compatibility encapsulation of window.requestAnimationFrame() () within _setAnimFrame() mentioned above.

Friends who are not familiar with the front-end may have questions, what is window.requestAnimationFrame() , what is it used for, and how does it work?

window.requestAnimationFrame()

Simply put, window.requestAnimationFrame() is used to request a repaint from the browser and call the specified callback function before repainting.

window.requestAnimationFrame() receives a callback as a parameter and returns an integer as a unique identifier. The browser will execute this callback before the next repaint; and a parameter is passed in when the callback is executed, and the value of the parameter is equal to the value returned by performance.now() .

The return value of performance.now() can be simply understood as the running length of the browser window, that is, the time difference from opening the window to the current moment.

MDN documentation: https://developer.mozilla.org/zh-CN/docs/Web/API/Performance/now

The number of callback function executions usually matches the number of browser screen refreshes, that is, for a display with a refresh rate of 60Hz, the browser will execute the callback function 60 times in one second.

This is the end of the description of window.requestAnimationFrame() . If you want to know more information, please search it yourself.

MDN documentation: https://developer.mozilla.org/zh-CN/docs/Web/API/Window/requestAnimationFrame

summary

Draw a picture to make a small summary of the engine startup process~

Main Loop

After some twists and turns, we finally came to the most anticipated main loop of the engine. Without further ado, let’s continue!

cc.director

cc.director object is an instance of the director class cc.Director . The engine mainly manages the logical flow of the game through cc.director object.

CCDirector.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCDirector.js

mainLoop()

🍖 cc.director.mainLoop() function may be one of the most critical logics in the engine, and it contains a lot of critical content.

Now let’s go inside mainLoop() function and take a look!

Here I selectively removed some of the code in the function and made some comments:

mainLoop: function(now) {
    // Calculate the "global" delta time (DeltaTime)
    // That is, the time interval from the last call to mainLoop this.calculateDeltaTime(now);
    // Update if the game is not paused if (!this._paused) {
        //Emit 'director_before_update' event this.emit(cc.Director.EVENT_BEFORE_UPDATE);
        //Call the start function of the newly added component (enabled) this._compScheduler.startPhase();
        //Call the update function of all components (enabled) this._compScheduler.updatePhase(this._deltaTime);
        // Update the scheduler (cc.Scheduler)
        this._scheduler.update(this._deltaTime);
        //Call lateUpdate function of all components (enabled) this._compScheduler.lateUpdatePhase(this._deltaTime);
        //Emit 'director_after_update' event this.emit(cc.Director.EVENT_AFTER_UPDATE);
        // Destroy the most recently removed entity (node)
        Obj._deferredDestroy();
    }
    //Emit 'director_before_draw' event this.emit(cc.Director.EVENT_BEFORE_DRAW);
    // Render the game scenerenderer.render(this._scene, this._deltaTime);
    //Emit 'director_after_draw' event this.emit(cc.Director.EVENT_AFTER_DRAW);
    // Update the event listener of the event manager (cc.eventManager has been deprecated)
    eventManager.frameUpdateListeners();
    // Accumulate the total number of frames of the game this._totalFrames++;
}

Portal: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/CCDirector.js#L843

Next, let's break down the key points in the main loop one by one.

ComponentScheduler

_compScheduler attribute in cc.director object is an instance of ComponentScheduler class.

Most of you may not have any impression of ComponentScheduler class, so let me briefly explain it.

The literal translation of the name ComponentScheduler is "component scheduler". As the name suggests, this class is used to schedule components.

In layman's terms, the ComponentScheduler class is used to centrally schedule (manage) the life cycle of all components ( cc.Component ) in the game scene.

The text is not intuitive enough, you will probably understand it after looking at the picture below:

component-scheduler.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/component-scheduler.js

startPhase

//Call the start function of the newly added component (enabled) this._compScheduler.startPhase();

The component's start callback function will be triggered before the component is activated for the first time, that is, before the first update is executed.

start callback will only be triggered once in the life of the component, the same is true for onLoad and onEnable .

It’s just that onLoad and onEnable are managed by instances of NodeActivator class:

onLoad is triggered when the node is activated onEnable is triggered when the component is enabled.

start will not be triggered until the next main loop mainLoop() .

🥁 NodeActivator

NodeActivator class is mainly used to enable and disable nodes and their components.

cc.director object has an instance _nodeActivator , and the enabling and disabling of all nodes in the game need to be operated through it.

Like this: cc.director._nodeActivator.activateNode(this, value);

node-activator.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/node-activator.js

updatePhase

//Call the update function of all components (enabled) this._compScheduler.updatePhase(deltaTime);

The component's update function is triggered once per frame.

lateUpdatePhase

//Call lateUpdate function of all components (enabled) this._compScheduler.lateUpdatePhase(deltaTime);

The lateUpdate function of the component will be triggered after update and scheduler cc.Scheduler are updated. Scheduler updates include easing, animation, and physics, which will be expanded upon below.

ParticleSystem

BTW, the particle system component ( cc.ParticleSystem ) is updated in the lateUpdate callback function.

CCParticleSystem.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/particle/CCParticleSystem.js

Tips

Please use update and lateUpdate callbacks with caution, because they are triggered for every frame. If there is too much logic in update or lateUpdate , the execution time of each frame (i.e. frame time) will be longer, resulting in lower frame rate or instability in the game.

📢 Please note that this does not mean you are not allowed to use it. You should still use it, but don't abuse it and don't put everything in it~

Scheduler

The _scheduler attribute of cc.director object is an instance of cc.Scheduler class.

cc.Scheduler is the class responsible for triggering the callback function.

Scheduler.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/Scheduler.js

💣You will never guess what will happen after the following line of code is executed.

// Update the scheduler (cc.Scheduler class instance)
this._scheduler.update(this._deltaTime);

_scheduler.update() function is used in cc.director.mainLoop() to distribute updates. Inside the scheduler ( cc.director._scheduler ), the updates of various system modules and component timers are triggered in sequence according to priority.

System Module

The update of the scheduler will first trigger the update of the following system modules:

• ActionManager
• AnimationManager
• CollisionManager
• PhysicsManager
• Physics3DManager
• InputManager

All of the above modules are registered with the scheduler using cc.director._scheduler.scheduleUpdate() , because these modules need to be updated every frame.

The priority of all modules except InputManager is cc.Scheduler.PRIORITY_SYSTEM , which is the system priority and will be triggered first.

ActionManager

ActionManager is the action manager, which is used to manage all actions in the game, that is, the easing system Action and Tween (in fact, they are essentially the same thing).

CCActionManager.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/actions/CCActionManager.js

AnimationManager

AnimationManager is an animation manager that manages all animations in the game and drives Animation components on the nodes to play animations.

animation-manager.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/animation/animation-manager.js

CollisionManager

CollisionManager is the collision component manager, which is used to process whether the collision components between nodes have collided and call the corresponding callback function.

CCCollisionManager.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/collider/CCCollisionManager.js

PhysicsManager

PhysicsManager is the physical system manager, which uses Box2D as the 2D physics engine internally, encapsulates it and opens some commonly used interfaces. At the same time, PhysicsManager is also responsible for managing the distribution of collision information.

CCPhysicsManager.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/physics/CCPhysicsManager.js

Physics3DManager

Physics3DManager is the 3D physics system manager. The 3D physics engines in Cocos Creator include Cannon.js and Builtin . Physics3DManager encapsulates a unified common interface for them.

physics-manager.ts: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/3d/physics/framework/physics-manager.ts

InputManager

InputManager is the input event manager, which is used to manage all input events. After the developer actively enables the accelerometer, the engine will periodically send cc.SystemEvent.EventType.DEVICEMOTION events through InputManager (the default interval is 0.2 seconds).

CCInputManager.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d\core\platform\CCInputManager.js

Component Timer

I believe most of you have used schedule() and scheduleOnce() interfaces of components, which are mainly used to repeatedly execute or schedule functions.

In fact, schedule() interface of cc.Component also relies on cc.Scheduler class, and specifically uses the _scheduler instance in cc.director object.

schedule() interface of the component adds a layer of encapsulation outside cc.director._scheduler.schedule() interface, with the component itself as target . In this way, the scheduled tasks in the component are bound to the component life cycle, and the scheduled tasks will also be removed when the component is destroyed.

scheduleOnce() interface adds another layer of encapsulation outside the component's schedule() interface, and is fixed to be executed only once after the specified time.

CCComponent.js: https://github.com/cocos-creator/engine/blob/2.4.3/cocos2d/core/components/CCComponent.js

[Documentation] Using the timer: http://docs.cocos.com/creator/manual/zh/scripting/scheduler.html

I also noticed that many of you are still not very clear about the difference and usage between component timers and setTimeout() and setInterval() , so let me take this opportunity to briefly explain it~

setTimeout & setInterval

Both setTimeout() and setInterval() are interfaces provided by browsers or runtimes such as Node.js.

The setTimeout() interface is used to set a timer that executes a function or a specified piece of code after the timer expires. The setInterval() interface is used to call a function or execute a code segment repeatedly with a fixed time delay between each call.

💡 One more little knowledge:

The minimum delay (interval) for setTimeout() and setInterval() in the browser is 4ms.

If it is an inactive (background) tab, the minimum delay (interval) is extended to 1000ms.

🌰 For example

If I set a timer to output a log every 500ms in the current tab, when I switch to another tab, the timer will become to output a log every 1000ms.

Like this, if you are interested, you can try it yourself:

setInterval(() => {
    console.log(new Date().getTime());
}, 500);
//Analog output//Tab in the foreground// 1604373521000
//1604373521500
// 1604373522000
// After switching to another tab page // 1604373523000
// 1604373524000
// 1604373525000

Differences & Usage

The component's timer depends on the engine's mainLoop() and the component itself. If the engine is paused, the component's timer will also be paused. If the component or the node where the component is located is destroyed, the timer will also become invalid.

Both setTimeout() and setInterval() depend on the current window object, which means that as long as the current browser tab is not closed, setTimeout() and setInterval() will still be executed.

When you need to time or repeatedly execute a function or operate a node within a component, you can use the component's timer.

💬 Let's imagine a scenario:

Use setInterval() in a script in the current scene to repeatedly move a node in the scene. What happens when we switch scenes?

When the timer calls the callback again to try to move the node, it will not be able to find the target node and report an error, because the node has been destroyed along with the previous scene, while the timer is still executing.

In this case, using the component's timer will not have this problem, because the timer will be cleared when the component is destroyed.

When we need to execute something that is not related to the game scene, we can consider using setTimeout() or setInterval() .

🎃 Of course, if you can use a component timer, it is better to use the component timer~

summary

Let's still draw a picture to briefly summarize Scheduler .

Summarize

This is the end of the interpretation of the engine startup process and main loop.

Finally, let's draw a picture to make a final summary~

The above is the detailed content of interpreting the engine startup and main loop of CocosCreator source code. For more information about CocosCreator source code interpretation, please pay attention to other related articles on 123WORDPRESS.COM!