重开发人员的劳动成果,转载的时候请务必注明出处:http://blog.csdn.net/haomengzhu/article/details/30478251
Cocos2d 的一大特色就是提供了事件驱动的游戏框架,
引擎会在合适的时候调用事件处理函数。我们仅仅须要在函数中加入对各种游戏事件的处理,
就能够完毕一个完整的游戏了。
比如,为了实现游戏的动态变化。Cocos2d 提供了两种定时器事件。
为了响应用户输入,Cocos2d 提供了触摸事件和传感器事件;
此外,Cocos2d 还提供了一系列控制程序生命周期的事件。
Cocos2d 的调度原理管理着全部的事件,Cocos2d 已经为我们隐藏了游戏主循环的实现。
首先来看看游戏实现的原理:
游戏乃至图形界面的本质是不断地画图。然而画图并非任意的。不论什么游戏都须要遵循一定的规则来呈现出来,这些规则就体现为游戏逻辑。游戏逻辑会控制游戏内容。使其依据用户输入和时间流逝而改变。
因此,游戏能够抽象为不断地反复下面动作:
处理用户输入 ;
处理定时事件 ;
画图 。
游戏主循环就是这种一个循环,它会重复运行以上动作,保持游戏进行下去,直到玩家退出游戏。
在 Cocos2d-x 3.0 中,以上的动作包括在 Director 的某个方法之中,而引擎会依据不同的平台设法使系统不断地调用这种方法,从而完毕了游戏主循环。
在cocos2d-x 3.0中。Director 包括一个管理引擎逻辑的方法,它就是 Director::mainLoop()方法。
这种方法负责调用定时器,画图,发送全局通知,并处理内存回收池。
该方法按帧调用, 每帧调用一次。而帧间间隔取决于两个因素,一个是预设的帧率,默觉得 60 帧每秒;
还有一个是每帧的计算量大小。
当逻辑 处理与画图计算量过大时,设备无法完毕每秒 60 次绘制。此时帧率就会减少。
mainLoop()方法会被定时调用。然而在不同的平台下它的调用者不同。
通常 Application 类负责处理平台相关的任务,当中就包括了对 mainLoop()的调用。
不同的平台详细实现也不同样,详细可參考cocos2dplatform文件夹;
mainLoop()方法是定义在 Director 中的抽象方法。它的实现位于同一个文件里的 DisplayLinkDirector类中;
virtual void mainLoop() = 0;
详细实现是:
void DisplayLinkDirector::mainLoop() { if (_purgeDirectorInNextLoop) { _purgeDirectorInNextLoop = false; purgeDirector(); } else if (! _invalid) { drawScene(); // release the objects //释放资源对象 PoolManager::getInstance()->getCurrentPool()->clear(); } }
上述代码主要包括例如以下 3 个步骤。
1、推断是否须要释放 Director,假设须要,则删除 Director 占用的资源。通常,游戏结束时才会运行这个步骤。
2、调用 drawScene()方法,绘制当前场景并进行其它必要的处理。
3、弹出自己主动回收池。使得这一帧被放入自己主动回收池的对象所有释放。
mainLoop()把内存管理以外的操作都交给了 drawScene()方法,因此关键的步骤都在 drawScene()方法之中;
再来看看drawScene方法:
void Director::drawScene() { // calculate "global" dt //计算全局帧间时间差 dt calculateDeltaTime(); // skip one flame when _deltaTime equal to zero. if(_deltaTime < FLT_EPSILON) { return; } if (_openGLView) { _openGLView->pollInputEvents(); } //tick before glClear: issue #533 if (! _paused) { _scheduler->update(_deltaTime); _eventDispatcher->dispatchEvent(_eventAfterUpdate); } glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); /* to avoid flickr, nextScene MUST be here: after tick and before draw. XXX: Which bug is this one. It seems that it can't be reproduced with v0.9 */ if (_nextScene) { setNextScene(); } kmGLPushMatrix(); // global identity matrix is needed... come on kazmath! kmMat4 identity; kmMat4Identity(&identity); // draw the scene //绘制场景 if (_runningScene) { _runningScene->visit(_renderer, identity, false); _eventDispatcher->dispatchEvent(_eventAfterVisit); } // draw the notifications node //处理通知节点 if (_notificationNode) { _notificationNode->visit(_renderer, identity, false); } if (_displayStats) { showStats(); } _renderer->render(); _eventDispatcher->dispatchEvent(_eventAfterDraw); kmGLPopMatrix(); _totalFrames++; // swap buffers //交换缓冲区 if (_openGLView) { _openGLView->swapBuffers(); } if (_displayStats) { calculateMPF(); } }
能够分析出:
在主循环中,我们主要进行了下面 3 个操作。
1、调用了定时调度器的 update 方法,引发定时器事件。
2、假设场景须要被切换,则调用 setNextStage 方法。在显示场景前切换场景。
3、调用当前场景的 visit 方法,绘制当前场景。
在游戏主循环 drawScene 方法中。我们能够看到每一帧引擎都会调用 _scheduler的 update 方法。
【Scheduler *_scheduler;】_scheduler 是 Scheduler 类型的对象,是一个定时调度器。
所谓定时调度器,就是一个管理全部节点定时器的对象。
它负责记录定时器。并在合适的时间触发定时事件。
再来分析一下定时器的情况:
Cocos2d-x 提供了两种定时器,各自是:
update 定时器。每一帧都被触发。使用 scheduleUpdate 方法来启用。
schedule 定时器,能够设置触发的间隔,使用 schedule 方法来启用。
看下Node中的实现:
void Node::scheduleUpdateWithPriority(int priority) { _scheduler->scheduleUpdate(this, priority, !_running); } void Node::schedule(SEL_SCHEDULE selector, float interval, unsigned int repeat, float delay) { CCASSERT( selector, "Argument must be non-nil"); CCASSERT( interval >=0, "Argument must be positive"); _scheduler->schedule(selector, this, interval , repeat, delay, !_running); }
当中 _scheduler是 Scheduler 对象。
能够看到。这两个方法的内部除去检查參数是否合法,仅仅是调用了 Scheduler提供的方法。
换句话说,Node 提供的定时器仅仅是对 Scheduler 的包装而已。
不仅这两个方法如此,其它定时器相关的方法也都是这样。
Scheduler的分析
经过上面的分析,我们已经知道 Node 提供的定时器不是由它本身而是由 Scheduler管理的。
因此,我们把注意力转移到定时调度器上。
显而易见。定时调度器应该对每个节点维护一个定时器列表。在恰当的时候就会触发其定时事件。
Scheduler的主要成员请查看:cocos2dCCScheduler.h
为了注冊一个定时器,开发人员仅仅要调用调度器提供的方法就可以。
同一时候调度器还提供了一系列对定时器的控制接口。比如暂停和恢复定时器。
在调度器内部维护了多个容器,用于记录每一个节点注冊的定时器;
同一时候。调度器会接受其它组件(通常 与平台相关)的定时调用。随着系统时间的改变驱动调度器。
调度器能够随时增删或改动被注冊的定时器。
详细来看,调度器将 update 定时器与普通定时器分别处理:
当某个节点注冊 update 定时器时,调度器就会把节点加入到 Updates 容器中,
即struct _hashUpdateEntry *_hashForUpdates里面;
为了提高调度器效率。Cocos2d-x 使用了散列表与链表结合的方式来保存定时器信息;
当某个节点注冊普通定时器时,调度器会把回调函数和其它信息保存到 Selectors 散列表中。
即struct _hashSelectorEntry *_hashForTimers里面。
在游戏主循环中。我们已经见到了 update 方法。
能够看到,游戏主循环会不停地调用 update 方法。
该方法包括一个实型參数,表示两次调用的时间间隔。
在该方法中,引擎会利用两次调用的间隔来计算何时触发定时器。
我们再来分析下 update 方法的工作流程:
// main loop void Scheduler::update(float dt) { _updateHashLocked = true; //a.预处理 if (_timeScale != 1.0f) { dt *= _timeScale; } // // Selector callbacks // // Iterate over all the Updates' selectors //b.枚举全部的 update 定时器 tListEntry *entry, *tmp; // updates with priority < 0 //优先级小于 0 的定时器 DL_FOREACH_SAFE(_updatesNegList, entry, tmp) { if ((! entry->paused) && (! entry->markedForDeletion)) { entry->callback(dt); } } // updates with priority == 0 //优先级等于 0 的定时器 DL_FOREACH_SAFE(_updates0List, entry, tmp) { if ((! entry->paused) && (! entry->markedForDeletion)) { entry->callback(dt); } } // updates with priority > 0 //优先级大于 0 的定时器 DL_FOREACH_SAFE(_updatesPosList, entry, tmp) { if ((! entry->paused) && (! entry->markedForDeletion)) { entry->callback(dt); } } // Iterate over all the custom selectors //c.枚举全部的普通定时器 for (tHashTimerEntry *elt = _hashForTimers; elt != nullptr; ) { _currentTarget = elt; _currentTargetSalvaged = false; if (! _currentTarget->paused) { // The 'timers' array may change while inside this loop //枚举此节点中的全部定时器 //timers 数组可能在循环中改变,因此在此处须要小心处理 for (elt->timerIndex = 0; elt->timerIndex < elt->timers->num; ++(elt->timerIndex)) { elt->currentTimer = (Timer*)(elt->timers->arr[elt->timerIndex]); elt->currentTimerSalvaged = false; elt->currentTimer->update(dt); if (elt->currentTimerSalvaged) { // The currentTimer told the remove itself. To prevent the timer from // accidentally deallocating itself before finishing its step, we retained // it. Now that step is done, it's safe to release it. elt->currentTimer->release(); } elt->currentTimer = nullptr; } } // elt, at this moment, is still valid // so it is safe to ask this here (issue #490) elt = (tHashTimerEntry *)elt->hh.next; // only delete currentTarget if no actions were scheduled during the cycle (issue #481) if (_currentTargetSalvaged && _currentTarget->timers->num == 0) { removeHashElement(_currentTarget); } } // delete all updates that are marked for deletion // updates with priority < 0 //d.清理全部被标记了删除记号的 update 方法 //优先级小于 0 的定时器 DL_FOREACH_SAFE(_updatesNegList, entry, tmp) { if (entry->markedForDeletion) { this->removeUpdateFromHash(entry); } } // updates with priority == 0 //优先级等于 0 的定时器 DL_FOREACH_SAFE(_updates0List, entry, tmp) { if (entry->markedForDeletion) { this->removeUpdateFromHash(entry); } } // updates with priority > 0 //优先级大于 0 的定时器 DL_FOREACH_SAFE(_updatesPosList, entry, tmp) { if (entry->markedForDeletion) { this->removeUpdateFromHash(entry); } } _updateHashLocked = false; _currentTarget = nullptr; #if CC_ENABLE_SCRIPT_BINDING // // Script callbacks // // Iterate over all the script callbacks //e.处理脚本引擎相关的事件 if (!_scriptHandlerEntries.empty()) { for (auto i = _scriptHandlerEntries.size() - 1; i >= 0; i--) { SchedulerScriptHandlerEntry* eachEntry = _scriptHandlerEntries.at(i); if (eachEntry->isMarkedForDeletion()) { _scriptHandlerEntries.erase(i); } else if (!eachEntry->isPaused()) { eachEntry->getTimer()->update(dt); } } } #endif // // Functions allocated from another thread // // Testing size is faster than locking / unlocking. // And almost never there will be functions scheduled to be called. if( !_functionsToPerform.empty() ) { _performMutex.lock(); // fixed #4123: Save the callback functions, they must be invoked after '_performMutex.unlock()', otherwise if new functions are added in callback, it will cause thread deadlock. auto temp = _functionsToPerform; _functionsToPerform.clear(); _performMutex.unlock(); for( const auto &function : temp ) { function(); } } }
借助凝视。可以看出 update 方法的流程大致例如以下所看到的。
1、參数 dt 乘以一个缩放系数,以改变游戏全局的速度,当中缩放系数能够由 Scheduler的TimeScale属性设置。
2、分别枚举优先级小于 0、等于 0、大于 0 的 update 定时器。
假设定时器没有暂停,也没有被标记为即将删除,则触发定时器。
3、枚举全部注冊过普通定时器的节点,再枚举该节点的定时器。调用定时器的更新方法,从而决定是否触发该定时器。
4、再次枚举优先级小于 0、等于 0、大于 0 的 update 定时器,移除前几个步骤中被标记了删除记号的定时器。
我们暂不关心脚本引擎相关的处理。
对于 update 定时器来说,每一节点仅仅可能注冊一个定时器,
因此调度器中存储定时器数据的结构体tListEntry *entry主要保存了注冊者与优先级。
对于普通定时器来说,每个节点能够注冊多个定时器,
引擎使用回调函数(选择器)来区分同一节点下注冊的不同定时器。
调度器为每个定时器创建了一个 Timer 对象,
它记录了定时器的目标、回调函数、触发周期、反复触发还是仅触发一次等属性。
Timer 也提供了 update 方法。它的名字和參数都与 Scheduler 的 update 方法一样,
并且它们也都须要被定时调用。
不同的是。Timer 的 update 方法会把每一次调用时接收的时间间隔 dt 积累下来,
假设经历的时间达到了周期就会引发定时器的定时事件。
第一次引发了定时事件后,假设是仅触发一次的定时器。
则 update 方法会中止,否则定时器会又一次计时,从而重复地触发定时事件。
来看看Timer的update方法:
void Timer::update(float dt) { if (_elapsed == -1) { _elapsed = 0; _timesExecuted = 0; } else { if (_runForever && !_useDelay) {//standard timer usage _elapsed += dt; if (_elapsed >= _interval) { trigger(); _elapsed = 0; } } else {//advanced usage _elapsed += dt; if (_useDelay) { if( _elapsed >= _delay ) { trigger(); _elapsed = _elapsed - _delay; _timesExecuted += 1; _useDelay = false; } } else { if (_elapsed >= _interval) { trigger(); _elapsed = 0; _timesExecuted += 1; } } if (!_runForever && _timesExecuted > _repeat) { //unschedule timer cancel(); } } } }
再次回到 Scheduler 的 update 方法上来。
在步骤 c 中。程序首先枚举了每个注冊过定时器的对象,然后再枚举对象中定时 器相应的 Timer 对象。
调用 Timer 对象的 update 方法来更新定时器状态,以便触发定时事件。
至此。我们能够看到事件驱动的普通定时器调用顺序为:
系统的时间事件驱动游戏主循环,游戏主循环调用 Scheduler 的 update 方法,Scheduler 调用普通定时器相应的 Timer 对象的 update 方法。Timer
类的 update 方法调用定时器 相应的回调函数。
对于 update 定时器,调用顺序更为简单。因此前面仅列出了普通定时器的调用顺序。
同一时候,我们也能够看到,在定时器被触发的时刻,Scheduler 类的 update 方法正在迭代之中,
开发人员全然可能在定时器 事件中启用或停止其它定时器。
只是。这么做会导致 update 方法中的迭代被破坏。
Cocos2d-x 的设计已经考虑到了这个问题,採用了一些技巧避免迭代被破坏。
比如,update 定时器被删除时,不会直接删除,而是标记为将要删除。在定时器迭代完成后再清理被标记的定时器,这样就可以保证迭代的正确性。
Cocos2d-x 的设计使得非常多离散在各处的代码通过事件联系起来,在每一帧中起作用。
基于事件驱动的游戏框架易于掌握。使用灵活,并且全部事件串行地在同一线程中运行,不会出现线程同步的问题。
能够看到,Cocos2d-x是多么的强大!!。
小伙伴们,知道cococs2d-x是怎么调度了咩!。
咩!
!
郝萌主友情提示:
多看看源代码,你就能更了解cocos2d-x了、、、