Hash表所做的“野怪刷新”的演示

cccty1l

引用第19楼用户名是虾米于2008-10-29 21:38发表的  :
结构里应该是可以使用变量数组的，

有个局限就是  必须声明下数组的长度

受制于WE不支持二维数组，所以其实struct是不能使用变量数组的。

还有回兔子，那个半成品的演示只是在单位使用技能的时候才会有拖影，假若是要每时每刻都要其存在的话，
也不是不行，只是动作上很难保持统一，同时在函数方面就要做更多的判断。

我之前做过一个类似的东西，一会改一改发上来吧，缺点有好多，比较费资源，支持多人方面也不行。

另，我想，一个技能有必要做的支持多人么？在守卫或对抗类地图中，每个英雄的个性才是首要的，一个好的
点子可以给地图增色不少，同时也使得英雄更有特色，但是滥用的话反而影响效果，同时要支持多人的话，势
必要更多的工作和繁杂的触发，反而得不偿失。呵呵，不说啦，一会发演示。

w

相当强大。　支持。

我当时的白痴做法是留空。

比如给出  Bottom   和  Top后，我保证生成的timer肯定在这个区间。
（Bottom和Top的差不要太大，事实上，同时工作的timer不会有多少，2000应该是足够的）
而其它变量肯定落不到这个区间。

比如：　　32af2248   和32af4200这个区间，我就让生成的timer的handle值都落在这个区间，
之后用timer的handle减去那个32af2248，就一定不会有多大了，可以用做数组下标了。

范斌浩

相当强大。　支持。

无泪

      [s:166]

actboy168

我觉得第二个hash函数有些问题

在实际应用中经常要存储一些连续的handle，假设某handle使得ha=10、hb=10，那么他的第一和第二次探测分别是10和20；而他的下一个handle呢，ha=11、hb=9，第一和第二次探测分别是11和20；再下一个是12和20........也就是他们的第二次探测的值都是一样的，等于第二次探测就浪费了。

另一个问题是，hb太小容易造成“孤岛效应”，也就是hansh表里有效的元素都集中在一起，造成每次都必须探测多次才能找到合适的位置。

cccty1l

嗯，谢谢actboy168的指正。
话说我是在看了你做的物品合成的演示才知道Hash这东西的。然后才临时在百度上学习了下Hash表的使用方法。直到现在还是有很多东西不是很懂，希望你能多给我解释一下。
我是在某人的Blog里面了解到这个重Hash的方法的，而且他也说了在Key是随机的情况下使用这个方法是很好的，但是在魔兽中，很多单位或者计时器的Handle值都相差不大或者是连续的，这样就导致了第一次寻址后它们的地址是临近的，而且之后的地址散开也不是很大，就如你所说的“孤岛效应”。
我想请教下，现在我应当做哪些修改来提高这个算法的效率呢？

actboy168

第二个函数改成增函数，两个都是增函数，这样累加起来不同的handle值自然会越离越远.....