我希望这不会太开放。
我想知道是否有更好(对电池更友好)的方式来做到这一点 --
我有一个小型 HTML 5 游戏,在 Canvas 上绘制(假设为 500x500)。我有一些对象,它们的位置每 50 毫秒左右更新一次。我当前的实现每 50 毫秒重新绘制整个 Canvas 。我无法想象这对移动平台上的电池生命周期有多大好处。
有更好的方法吗?这一定是游戏的常见模式。
编辑:
根据要求,这里有一些更新:
现在,对象是通过弧线和直线绘制的几何基元。我不反对制作这些小的 png/jpg/gif 文件,而不是那样会有帮助。这些是小图形 -- 只有 15x15 左右。
随着游戏的进行,越来越多的屏幕会同时发生变化。但是,开始时,屏幕变化相对缓慢(对象每 50 毫秒随机移动几个像素)。
最佳答案
几乎所有像这样具有连续动画的游戏都会在每一帧重绘所有内容;聪明的更新算法仅适用于屏幕的一小部分发生变化时,并且有一个很好的规则可以找出与该部分重叠的内容。
这里是一些通用的优化建议:
确保尽可能多的图形由 GPU 而不是 CPU 处理。 (如果用户的浏览器不使用 GPU 进行 2D Canvas 渲染,这可能是不可能的,但是随着 HTML5 游戏的流行,升级可能会改变这一点。)
这意味着您应该避免精心设计的巧妙算法,以支持在 JS 代码中做尽可能少的工作——除非在很容易确定它不可见时避免执行大量绘图(例如在外面屏幕的边界)通常是值得的。
如果您的目标平台支持它(目前的移动设备通常不支持),请尝试使用 WebGL 而不是 2D Canvas。您将不得不做更多的细节工作,但 WebGL 允许您使用更有可能由 GPU 硬件高效提供的操作。
如果您的游戏变得闲置——也就是说,目前没有任何动画——停止重绘。停止更新循环,直到用户与游戏互动或发生超时。
将正在绘制的图形类型的详细信息添加到您的问题中可能会对您有所帮助(例如,您使用的是 Sprite 还是几何图元?您绘制的图像是否旋转/缩放?大部分屏幕是否发生变化,或者只是一些小物体?你混合了很多层吗?)甚至可能是一两张截图;然后我们可以建议哪种优化适合您的特定游戏。
关于HTML5 Canvas 和游戏编程,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10961795/