艰深问题：在确保效率的同时~视野~警戒范围~限RTS~

PassByYou

刚才做过一个估算，
一个视野为20x20的单位，在移动过程中会产生400次的视野巡检，如果地图上交织多个单位，这还会涉及到使用地图做数据暂存的交织视野~

一个部队，预定数量为50~视野预定为15x15，这50个人在移动过程中~会发生每rule frame~产生50*15*15的巡检数据~如果把图形~还有其他算法，包括武器伤害种类算法~finding path算法~移动state检测算法~把这些都算起来~在一枚p4 cpu上跑~这构成问题吗？？~

Liker

看看魔兽就知道了，基本视野检测的判断间隔在1秒以上

hanma

偶做了个四叉树，高度优化后可在15毫秒内在100万个单位中寻找6万个单位的视野。

PassByYou

同道。握手。

保守估算如下：rule frame平均每秒刷新在30左右，3D frame不算在其内，视野和警戒范围，按移速计算的话，平均每个单位每秒移动2格，也就是说，one object每妙触发2次15*15的巡检，目前rts负载量都在100单位以上，在rule frame的计算结果为：100*15*15*2（保守结果）

另外，4x无用，巡检的功能是刷新范围，范围可以用map pane单位作为触发接口，不需要遍厉，只需要在移动过程中刷新范围，用作视野模拟用~btree和4x都派不上。

btree在高层AI的状态分析上倒是可以用上。内核上不可用。

PassByYou

把cpu的idle time算进来，拿满负荷刷范围虽然效率高，如果把图形，AI，还有RULE一些算法都开销完的话，这个时候cpu的idle time是很低的。所以根本不能用4x来处理

仔细想了一下，范围计算的数据链表结构也很考究。我用asm在完成数据链的r/w，不然效率提不起来。

tsaoyi

我有一个想法不知道可行不可行。当n个兵在一起的话，且他们之间的距离不超过各自的警戒线，那么他们的警戒线就取最外围的境界线，当中的士兵，只要等待最外面警戒线报警然后做出处理，就像把很多橡皮泥涅成一块一样的意思。

PassByYou

多人视野判断存在object连接问题~而真正涉及到运算量的是移动视野~既object move过程中的视野巡检~如果是像你所说的多人判断外围~不是不可行，而是如果这样做，有多复杂的问题~这种外围视野在移动过程中能够用多简单的方式来实现呢？~no~个人感觉外围判断根本无从简单~除非你开发像征服美洲类的游戏~在游戏中存在group move~group command~之类的~这样就可以实现多人外围~~

计算量的陷阱在这里~我给指出来~方便理解~~

假设一个object的10*10的视野检定~他最大的检定量是在他移动的时候~这时候会消耗掉大量的cpu idle time~因为10*10=100，他每走一步，他的视野都会被巡检100次~其实这100次是不断的重复检查~这时候完全可以省略掉很多重复的视野鉴定了~因为10的单向移动时~需要新增的巡检量是10~需要废弃的巡检量也是10~这是单向移动~如果是倾斜角度移动~新增的巡检量是20~废弃的也是20~

被计算下来，每单位100的检查量，这时候被省略掉了60%-90%之间~

楼上那位做过试验~6W单位的巡检~如果做个保守估计~6W的60分之一~那已经是1000单位了~在一个RTS引擎中负载1000单位的移动运算量~那是1000*10*4---1000*10*2之间的巡检量~这种运算量是不大的~就算在p133级别的cpu上也是完全能够负载得起的~更别说现在的p4芯片了~