style: {
tw: 30, th: 30,
tx: function () {
return 40 + index % 8 * 36;
},
ty: function () {
return 31 + Math.floor(index / 8) * 32;
}
}
canvas分层渲染
假设：游戏需要保持40帧，浏览器宽800高600，面积48万（后面称48万为1个屏幕面积）。
如果用同一个canvas来呈现，那么这个canvas的帧数40，每秒至少需要绘制40个屏幕面积。但是同一个坐标点很可能出现多个元素重叠的情况，例如底部的UI、血条、按钮就是重叠放置，他们又共同遮挡了场景地图。所以这些加在一起，每秒浏览器的绘制量很容易达到100个屏幕面积以上。
这个绘制是很难优化的，因为整个canvas画布的任何一处都在进行视图的更新：可能是玩家和动物的移动、可能是按钮的特效、可能是某个技能效果的变化。这样的话，即使玩家不动，由于衣服“随风飘飘”的效果（其实是精灵动画播放到下一张图），或者是地面上出现了一瓶药水，都要引起整个canvas的重绘。因为 游戏中几乎不可能出现某一帧的画面与上一帧毫无区别的情况，即使是游戏画面的一个局部，也很难保持不变 。整个游戏的画面永远在更新。
因为 游戏中几乎不可能出现某一帧的画面与上一帧毫无区别的情况 ，画面永远在更新。
因此，这次我采用了3个canvas重叠排布的方式。由于Easycanvas的事件处理支持传递，因此即使点到了最上面的canvas，如果没有任何元素结束了某一次点击，后面的canvas也可以接到这次事件。3个canvas分别负责UI、地面（地图）、精灵（人物、动物、技能特效等）：
这样分层的好处是，每层最大帧数可以根据需要来调整：
例如UI层，因为很多UI平时是不动的，即使动也不会需要太精密的绘制，所以可以适当降低帧数，例如降低到20。这样假如玩家的体力从100降低到20，那么可以在50ms内更新视图，而50ms的切换是玩家感觉不出来的。因为像体力这种 UI层数据的变化很难在很短的时间内连续变化多次，而50ms的延迟是人很难感知的，所以不需要频繁的绘制 。假如我们每秒节约了20帧，那么很可能可以节约10个屏幕面积的绘制。
再如地面，只有玩家移动的时候，地图才会变化。这样，如果玩家不动，那么每帧可以省去1个屏幕面积。由于需要保证玩家移动时的流畅感，地面的最大帧数不宜太低。假如地面为30帧，那么玩家不动时，每秒就可以节约30个屏幕面积的绘制（这个项目中，地图是几乎绘满屏幕的）。而且其它玩家、动物的移动不会改变地面，也不需要重绘地面这一层。
精灵层最大帧数不能降低，这层会展示游戏的人物动作等核心部分，所以最大帧数设置为40.