HTML5游戏开发之循环的控制(2)

3) 如何调试帧率
理想的状态是，将游戏控制在60帧，这样充分利用显示器的能力，为用户提供流畅的画面。但是，通常情况下还是比较困难的，随着游戏逻辑的复杂性，帧率一般情况下都会下降。如果可以有一种可视化的方法，帮助开发者去观察每次RequestAnimationFrame的执行时间，可以让开发者及时的发现一些耗时的操作，尽量保证每次RequestAnimationFrame的执行时间控制在16ms内完成。
虽然目前还没有发现同一的方法，但是Chrome提供了abut:tracing的标签页，可以辅助开发者，去一探RequestAnimationFrame的究竟。不过，困难的是，如果想完全读懂 about:tracing，需要对于chrome的架构以及渲染方式非常熟悉，在加上GPU的原因，很难一下子完全理解整个页面。
这里介绍一个简单的用法，如下图，是从我的同事Seth的Blog中复制的图片，（如果想了解更多内容，可以参考Box2D, Web workers, Better performance），可以注意到，图中有两个红线，红线之间的间隔是16毫秒，相信很容易想到，这是每帧执行的最佳时间。在about:tracing页面中，双击每个方块，可以放大并出现每个函数的名字，按G，就可以立即出现两边的红线。里面有个泛蓝色的模块，标志WebViewImp:animate，它就是负责执行RquestAnimationFrame，貌似它的执行时间没有超过16ms，但是不幸的，因为在执行完RequestAnimationFrame之后，浏览器还对于需要渲染的元素，执行组装和渲染操作，很明显下图中的渲染时间，超过了红线的范围，也就是超过了16ms，图形渲染的效率自然会降低到60帧一下。

function handleVisibilityChange() {
if (document.webkitHidden) {
if (playAnimation is true)
//continue to do this animation
}
}
document.addEventListener(“webkitvisibilitychange”, handleVisibilityChange, false); 

上面是一段简单的代码，在发现页面不被显示的时候，可以执行一些必须被执行的动画。
5) Webworker的作用
现在很多的游戏，都利用到了Box2d或者其他重力引擎，而这种重力引擎的计算，相当耗费时间，如果将这些计算放在RequestAnimationFrame里面，很容易就会将每次执行的时间，超过16ms。最好可以将这类高成本的计算，放在一个单独的线程，每次RequestAnimationFrame只需要取到结果就可以了。

以上就是HTML5游戏开发 之 循环的控制(2)的内容，更多相关内容请关注PHP中文网（www.gxlcms.com）！

查看更多关于HTML5游戏开发之循环的控制(2)的详细内容...