COCOS2DX WIN32 版本的CPU占用25%改良策略
2016-04-21 14:24
267 查看
猜测它有可能是在主循环里使用了 Sleep(0), 一搜,果然定位到具体代码,它位于 cocos2dx\platform\win32\CCApplication.cpp,大致长像如下:
也就是说,该循环除了执行 mainLoop 以外,花了大量时间在 检查消息和 Sleep(0) 上面。
并且,我还发现一个奇怪的现象(暂时还不清楚是为什么),即:
HelloCPP 项目的 AppDelegate.cpp 文件中有一行代码:
上面的 60 ,如果改大,不起任何作用,帧速始终是 60 不会变。但如果改到小于60,是可以起作用的。
于是,解决 CPU 占用的思路,始于 “是否可以降低循环精度” 的念头。
已知正常情况下,执行 Sleep(1) ,会睡大概 1/50 秒,这个时间并不精确也不准确,看上去无法满足 60 fps 这个流畅度需求。不过,如果游戏运行帧速不需要这么高,比如 30 fps ?? 则该方案大为可行。
经实际测试,将 Sleep(0) 改成 Sleep(1), 再将上面代码中的 60 改成 25, 效果非常显著。但另一个问题来了:如果每游戏循环做的事有点多,时间有点长,那么游戏将被拖慢。
原engine中,同步时间的代码如下:
因为每次在 nLast 中记录 nNow 时间,并用时间差与设定间隔作比较,时间差往往会比设定间隔要大,如果是在不精确的 Sleep(1) 以及每循环负担比较大的情况下,将导致每帧实际所花的时间,会超出设定间隔不少,从而拖慢游戏速度(如果游戏按帧步进计时的话)。
为解决这个问题,我用的是时间对齐的方式。其实就是改了一下更新 nLast 的表达式:
这样每帧的总消耗时间就相当的恒定了。
上面的问题解决并不算太完美。如何保持 60 fps 也能 cpu 0% 占用呢? 我考虑的方案是修改 Sleep(1) 的精度。
找了一下资料,发现 Winmm.lib 库中有 timeBeginPeriod(1); timeEndPeriod(1); 函数可以用于该目的,令 Sleep(1) 的精度提升到1毫秒级别,遂动手改之:
1. 添加 Winmm.lib 库的引用。我在这里采取了在 CCApplication.cpp 头部添加 #pragma comment(lib, "Winmm.lib")
语句的方式。
2. 在 while(1) 代码段的前后,分别放上 timeBeginPeriod(1); timeEndPeriod(1); 语句
这样就算完工了。
经测试,帧速设定在 59 fps 以内, cpu 都可以实现 0 占用 (i7 2600k)。设成 60 的话, cpu 占用会周期性的古怪浮动,暂时不明就里中。而设成
60+, cpu 将 100%。
不过该问题就算暂时告一段落,先将程序限定到 50 fps 好了,流畅,无问题,感觉上也方便计算...
1 | while ( 1 ) { |
2 | if ( 有消息 ) { |
3 | if ( 时间到 ) 更新计时, call 主循环函数; |
4 | else Sleep(0); |
5 | } |
6 | // 其他跳出循环判断代码 |
7 | } |
并且,我还发现一个奇怪的现象(暂时还不清楚是为什么),即:
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); |
if (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 也能 cpu 0% 占用呢? 我考虑的方案是修改 Sleep(1) 的精度。
找了一下资料,发现 Winmm.lib 库中有 timeBeginPeriod(1); timeEndPeriod(1); 函数可以用于该目的,令 Sleep(1) 的精度提升到1毫秒级别,遂动手改之:
1. 添加 Winmm.lib 库的引用。我在这里采取了在 CCApplication.cpp 头部添加 #pragma comment(lib, "Winmm.lib")
语句的方式。
2. 在 while(1) 代码段的前后,分别放上 timeBeginPeriod(1); timeEndPeriod(1); 语句
这样就算完工了。
经测试,帧速设定在 59 fps 以内, cpu 都可以实现 0 占用 (i7 2600k)。设成 60 的话, cpu 占用会周期性的古怪浮动,暂时不明就里中。而设成
60+, cpu 将 100%。
不过该问题就算暂时告一段落,先将程序限定到 50 fps 好了,流畅,无问题,感觉上也方便计算...
相关文章推荐
- cocos2dx libevent简介和使用
- Quick-cocos2d-x 与COCOS2DX 区别
- 比较Cocos2d-x v2.x与v3.x的截图功能
- COCOS2DX中的selector机制
- cocos2dx 3.2+ 项目创建与问题总汇
- cocos lua 加密与解密 混淆 (版本cocos3.4)
- cocos xcode提交错误解决方案
- COCOS2DX 与 UNITY3D 的发展浅谈
- 一、cocos2dx之如何优化内存使用(高级篇)
- 二、Cocos2dx中Android部分的c++和java实现相互调用(高级篇)
- cocos2dx编辑器cocostudio与cocosbuilder异同
- cocos2dx中Action汇总
- cocos2dx纹理缓存
- Cocos2dx制作抖动弹出对话框效果
- cocos2dx碰撞检测实现
- cocos2dx中的cocosDenshion对不同平台音频支持格式
- cocos2dx socket 通信
- 【COCOS2DX-ANDROID-游戏开发之二十】停止手打所有cpp文件到android.mk
- 我的cocos2D-X3.10安装之路
- cocos2d-x RenderTexture