看过去他的那个红色线段是更短点
666，你用A星还是这条路，你先去检查一下你A星到底哪里写错了再来讨论吧，我说了，你用小学数学算算你的直线长度
哥们你头晕了吗？怎么看都是下面那条更短吧
A星寻路就不能确保一定找到最短路径，是有误差的。编辑器的运行测试界面是有A星寻路和RCA寻路可选的，误差可能有但是不会很大。而且我用A星寻路出来的结果和RCA寻路的结果一样。
你到底懂没懂啊，我才放大了一点点，你要不放大一千倍再算算差距呢
你可用你自己的A星寻路算法算，看看是不是我那条路径。
你自己慢慢排查吧，我很懒兄弟
我用多种方式计算了两条路径的距离。只有在只允许四向移动的基础上数步数上面那条才会更好，无论是允许八向移动还是直接算欧几里得距离都是下面的更短
知道你很懒，讨论这么久一直是我给你提供案例，你从未提供过一个案例给我。性能差距上面已经给出，请以后不要再把我当犯人审问。我也期待有一天你能出个demo给大家验证一些。否则谁会商用你的项目。
我要看血
流成河！
好的，有误差我承认，不会像某人只会喊口号，啥事也不会干。
查看了打印结果，下面那条是23，加上一个位移就是24。上面那条是28。
这个结果是A星和RCA都是相同的寻路结果。寻路并不能保证最短，有一定的误差，都是可接受范围
你跟我的差距就像这个4一样，在放大一千倍的时候，4000就是你我之间的鸿沟，结束吧
你的RCA有这个误差没问题。但是有一个另外的问题，你的A*不该找到上面那条路径，应该找到下面那条
1赞
你可以用你的算法看看，是什么路径，亲自验证一些。
我也早忍不了你了，你别把自己太当回事，这样结束吧。
呃……你用的是四向移动的A*吗？那找到上面那条挺合理的
A星本身就存在寻到的路径不一定最短，这个可以网上查看一些A星寻路的相关概念，确实会提到无法确保寻到最短路径。
我映像中A*在自己的规则中是可以保证最优的，你这个显然在八向移动的情况下绝对不最优，但是四向移动就刚刚好可以最优。基本上就可以判断出你这是四向移动了。
网址： PathFinding.js
（注：不是我写的）
1赞
感谢SmallMain的付出，花了这么多时间这么晚做了这个结果对比图，跟我的预期差不多。
正如我贴子里开始说到，地图初始化前要烘焙，也就是查找全地图的墙角并且按规则关联好他们的直达关系，地图构建初始化了一个地图数据的存储数据结构，对25万格子的烘焙和地图数据存储确实会有几秒的烘焙时间（不同设备因处理能力不同而烘焙时间不同），寻路速度和我预估的一样，比普通的A星快很多，但是应该不止你说的14倍。
Go语言版每次寻路完都会执行一次ResetMap，用于下次的寻路，对25万格子做数据重置绝对是个重大消耗。你应该 下面截图里大方框里的代码也算进消耗。当然可以帮他先把无关的打印代码给去了。
A星算法之前我也写有，我已经把这个算法优化到极致了。A星对比A星，相信我写的算法的效率也远在他之上。
你下载我的基础框架项目，在代码不动的情况下默认就是A星算法。
代码在下面截图
希望大佬能在帮验证一次。
前提：把go语言版的ResetMap也就是重置地图的代价算上（每次寻路go版都要重置地图）。
1、再次对比一下我写的RCA算法和Go语言版的A星算法的消耗代价。
2、对比一下我写的A星算法和Go语言版的A星算法的消耗代价。（先把最大寻路深度设置到100000）
对比完，让大家得到一个真正的结论，这里的争论点就终结了。
最后说一下我的烘焙消耗，自己有办法处理，就是在地图编辑器编辑时顺便把烘焙数据导出，游戏运行时就无需烘焙了，地图数据文件大0.5-1倍而已，地图数据文件本来就没多大，影响不了多少。
不会是推广卖地图代码的吧，停止不要占用论坛资源