之前简化公式的时候用代数 c = roleId*root3/2带入的, 结果简化完把后面的root3/2忘记了搞出个逗比的公式....
这两天抽空重新计算了下,并带来了一个新的更容易理解的公式。
二楼更容易理解的新公式
三楼原公式修正,代码最少的公式
四楼变形格子判定公式,用四边形做的例子,此公式可以配合二三楼的六边形甚至任何形状的二维图形偏移都可以。
另外关于说公式法耗时比较多和 float误差 在大型地形会导致偏移的问题。
首先这些公式是通用公式,不受屏幕大小,缩放,边界等影响。而数组缓存是针对项目的,数组必须和格子占屏幕像素的大小保持一致才可以,或许缩小没问题,放大在边缘上一定会不准,也不能处理小数情况下的边界。不过数组也有好处,其实就是提前算出区域内格子的计算结果,可以在不改动代码的情况下更换任意的格子形状。之前说那些细微问题其实也是在抬杠,因为玩家肯定无法分辨小于一两个像素的误差^^。所以我把你的做法也链接过来了。
http://hi.baidu.com/rvcrdmzbvrbemtq/item/af8a5789b499e2deee083d6f
如果根据项目对格子进行一些限定,公式可以继续简化。而且这些公式的耗时完全可以忽略不计,没有用到任何耗时的计算处理单元,即使有些开方三角函数之类的也都是常量无需没帧计算。
float要是怕有误差可以用double, double要是还有误差可以每过几千万个格子设置个偏移量依然可以保证误差在允许范围之内。
这两天抽空重新计算了下,并带来了一个新的更容易理解的公式。
二楼更容易理解的新公式
三楼原公式修正,代码最少的公式
四楼变形格子判定公式,用四边形做的例子,此公式可以配合二三楼的六边形甚至任何形状的二维图形偏移都可以。
另外关于说公式法耗时比较多和 float误差 在大型地形会导致偏移的问题。
首先这些公式是通用公式,不受屏幕大小,缩放,边界等影响。而数组缓存是针对项目的,数组必须和格子占屏幕像素的大小保持一致才可以,或许缩小没问题,放大在边缘上一定会不准,也不能处理小数情况下的边界。不过数组也有好处,其实就是提前算出区域内格子的计算结果,可以在不改动代码的情况下更换任意的格子形状。之前说那些细微问题其实也是在抬杠,因为玩家肯定无法分辨小于一两个像素的误差^^。所以我把你的做法也链接过来了。
http://hi.baidu.com/rvcrdmzbvrbemtq/item/af8a5789b499e2deee083d6f
如果根据项目对格子进行一些限定,公式可以继续简化。而且这些公式的耗时完全可以忽略不计,没有用到任何耗时的计算处理单元,即使有些开方三角函数之类的也都是常量无需没帧计算。
float要是怕有误差可以用double, double要是还有误差可以每过几千万个格子设置个偏移量依然可以保证误差在允许范围之内。