18、Cocos2dx 3.0游戏开发找小三之cocos2d-x,请问你是怎么调度的咩

重开发人员的劳动成果,转载的时候请务必注明出处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()的调用。
不同的平台详细实现也不同样,详细可參考cocos\2d\platform文件夹;

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的主要成员请查看:cocos\2d\CCScheduler.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了、、、

posted @ 2017-06-25 13:33  zsychanpin  阅读(264)  评论(0)    收藏  举报