COCOS2DX WIN32 版本的CPU占用25%改良策略

发布时间：2020-12-14 19:19:45 所属栏目：百科来源：网络整理

导读：猜测它有可能是在主循环里使用了 Sleep(0),一搜，果然定位到具体代码，它位于 cocos2d xplatformwin32CCApplication.cpp，大致长像如下： 1 while ( 1 ) { 2 if ( 有消息 ) { 3 ( 时间到 ) 更新计时,call 主循环函数; 4 else Sleep(0); 5 } 6 // 其他跳出

猜测它有可能是在主循环里使用了 Sleep(0),一搜，果然定位到具体代码，它位于cocos2dxplatformwin32CCApplication.cpp，大致长像如下：

 
        1 
        while( 1 ) { 
      
    2 
       if( 有消息 ) { 
      
    3 
       ( 时间到 ) 更新计时,call 主循环函数; 
      
4

elseSleep(0);

}

6 // 其他跳出循环判断代码

}

也就是说，该循环除了执行 mainLoop 以外，花了大量时间在检查消息和 Sleep(0) 上面。

并且，我还发现一个奇怪的现象（暂时还不清楚是为什么），即：

HelloCPP 项目的 AppDelegate.cpp 文件中有一行代码：

// set FPS. the default value is 1.0/60 if you don't call this

pDirector->setAnimationInterval(1.0 / 60);

上面的 60 ，如果改大，不起任何作用，帧速始终是 60 不会变。但如果改到小于60，是可以起作用的。

于是，解决CPU占用的思路，始于 “是否可以降低循环精度” 的念头。

已知正常情况下，执行 Sleep(1) ，会睡大概 1/50 秒，这个时间并不精确也不准确，看上去无法满足 60 fps 这个流畅度需求。不过，如果游戏运行帧速不需要这么高，比如 30 fps ?? 则该方案大为可行。

经实际测试，将 Sleep(0) 改成 Sleep(1),再将上面代码中的 60 改成25,效果非常显著。但另一个问题来了：如果每游戏循环做的事有点多，时间有点长，那么游戏将被拖慢。

原engine中，同步时间的代码如下：

QueryPerformanceCounter(&nNow);

(nNow.QuadPart - nLast.QuadPart > m_nAnimationInterval.QuadPart) {

nLast.QuadPart = nNow.QuadPart;

因为每次在 nLast 中记录 nNow 时间，并用时间差与设定间隔作比较，时间差往往会比设定间隔要大，如果是在不精确的 Sleep(1) 以及每循环负担比较大的情况下，将导致每帧实际所花的时间，会超出设定间隔不少，从而拖慢游戏速度（如果游戏按帧步进计时的话）。

为解决这个问题，我用的是时间对齐的方式。其实就是改了一下更新 nLast 的表达式：

nLast.QuadPart = nNow.QuadPart - (nNow.QuadPart%m_nAnimationInterval.QuadPart);

这样每帧的总消耗时间就相当的恒定了。

上面的问题解决并不算太完美。如何保持 60 fps 也能cpu0%占用呢？　我考虑的方案是修改 Sleep(1) 的精度。

找了一下资料，发现 Winmm.lib 库中有 timeBeginPeriod(1); timeEndPeriod(1); 函数可以用于该目的，令 Sleep(1) 的精度提升到1毫秒级别，遂动手改之：

1. 添加 Winmm.lib 库的引用。我在这里采取了在 CCApplication.cpp 头部添加 #pragmacomment(lib,"Winmm.lib") 语句的方式。

2. 在 while(1) 代码段的前后，分别放上 timeBeginPeriod(1); timeEndPeriod(1); 语句

这样就算完工了。

经测试，帧速设定在 59 fps 以内，cpu都可以实现 0占用(i7 2600k)。设成 60 的话，cpu占用会周期性的古怪浮动，暂时不明就里中。而设成 60+,cpu将 100%。

不过该问题就算暂时告一段落，先将程序限定到 50 fps 好了，流畅，无问题，感觉上也方便计算...

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!