9RIA.com天地会 - 论坛 - Powered by Discuz! Board

标题: [教程] [转载]AS3实现RPG游戏地图引擎 [打印本页]

作者: aobject 时间: 2008-11-16 20:17 标题: [转载]AS3实现RPG游戏地图引擎

最近在学习rpg碰撞检测,找到一遍好文,现在贴出来和大家一起分享
原文来自于http://bbs.mhhf.net/showtopic-361197.html,作者是SKDD

目前已经完成精确到像素的任意不规则形状的碰撞检测算法。同时也考虑将地图信息转为二维数组以便A*自动寻径。这样在操作上用碰撞，AI上用A*，一定能给玩家带来完美的游戏体验。

这里的碰撞检测主要依靠封装好的类PPCD（perfectPixelCollisionDetection），它的接口如下：

类PPCD：

1. 返回发生碰撞的矩形边界：

getCollisionRect （ target1:DisplayObject,
target2:DisplayObject,
commonParent:DisplayObjectContainer,
pixelPrecise:Boolean = true,
tolerance:Number = 0 ):Rectangle

复制代码

2. 返回发生碰撞的矩形边界的中心点：

getCollisionPoint （ target1:DisplayObject,
target2:DisplayObject,
commonParent:DisplayObjectContainer,
pixelPrecise:Boolean = true,
tolerance:Number = 0 ):Point

复制代码

3. 验证两个对象是否碰撞：

isColliding （ target1:DisplayObject,
target2:DisplayObject,
commonParent:DisplayObjectContainer,
pixelPrecise:Boolean = true,
tolerance:Number = 0 ):Boolean

复制代码

参数说明：

target1，target2：需要做碰撞检测的两个对象；
commonParent：两个对象所在的共同的容器；
pixelPreciese：是否精确到像素。若设置为false，则和DisplayObject.hitTestObject()工作原理相同。
tolerance：容许量，默认为0。这个数值设置开始进行碰撞检测的DisplayObject的最小alpha值。比如有个对象有阴影效果，其阴影的alpha值大概在20以下。那么如果在进行碰撞检测的时候不希望把阴影也包含进去，则需要将tolerance设置为20。否则另外一个物体碰到阴影也算有碰撞。

工作原理说明：

1. 找出两个对象边界矩形的交叉区域，若没有则没有发生碰撞
2. 创建一个与交叉区域同样大小的bitmap
3. 将第一个对象相交的部分以红色绘制在bitmap中
4. 将第二个对象的相交部分以白色绘制在bitmap中，BlendMode（混合模式）为DIFFERENCE。
5. 找出颜色为cyan的区域并返回其边界矩形。若没有则说明没有发生碰撞

此算法快速高效，一次检测只需要花2-3ms的时间。详细的算法参见源文件PPCD.fla，另有2个SWF演示：

1. 拖动小球，当小球碰到不规则物体时碰撞区域的边界矩形会以绿色标记出来，同时bitmap会在左上角显示。注意物体的阴影部分没有参与碰撞检测（合理设置tolerance参数）。
http://www.namipan.com/d/5e62326 ... 44e3767b05207070000
http://www.fs2you.com/files/98e07085-49dc-11dd-b7b8-0014221f4662/

2. 纯演示动画，看就好。^-^
http://www.namipan.com/d/6456a50 ... cbda4e56ea196070000
http://www.fs2you.com/files/98f32f1c-49dc-11dd-991f-0014221f4662/

有了这样一个强大的类，像素级的碰撞检测就不成问题了。不过因为PPCD类返回的是边界矩形，以及人物可以在不同的方向以不同的方式碰撞，再加上人物碰到障碍物之后需要有一定的自动“滑动”的功能，碰撞检测的逻辑还是挺复杂的，下面简要介绍一下。

碰撞检测逻辑

比较长和复杂，因为碰撞情况很多，准备好@_@哦？ ^^b
详细算法在5楼和6楼，帖子超长了，呵呵。

SWF效果预览：

曲线为主：
http://www.namipan.com/d/9862425 ... d6a5c4fd2276e1b0000
http://www.fs2you.com/files/98fb1375-49dc-11dd-998c-0014221f4662/

直线为主：
http://www.namipan.com/d/4205132 ... b458a61e8386d1b0000
http://www.fs2you.com/files/98fda719-49dc-11dd-9109-0014221f4662/

源文件：http://www.namipan.com/d/f960d7b ... 799d0efcb500c930100
http://www.fs2you.com/files/99003323-49dc-11dd-9d8e-0014221f4662/

目前没有发现BUG，不过还没有经过仔细调试，不敢保证完美。如果有朋友不幸遇见BUG了M我一下呀，谢谢咯~~ ^-^

[ 本帖最后由 aobject 于 2008-11-16 20:27 编辑 ]

作者: aobject 时间: 2008-11-16 20:20

首先来回忆一下人物移动在程序中的控制方法。舞台上的人物man具有成员dirx和diry，它们的值可以等于-step，0或step。step是每次移动的步长。man在发生ENTER_FRAME事件的时候将自己的x和y分别以dirx和diry递增，以达到移动的目的。当玩家按下键盘或鼠标后，人物需要运动的方向由onDirEvent或onMouseEvent函数解析出来并存放到dirArr数组，然后调用函数setDir来适当更改man.dirx和man.diry以改变人物的运动状态。

人物的8方向运动包含4个轴向和4个斜向。斜向分解开来其实就是人物同时在x向和y向运动，所以在写代码的时候是不需要单独处理的。那么只需要考虑人物在一个轴向运动时可能发生的各种碰撞情况，另一个轴向如法炮制就可以了。在具体讨论之前，先有必要介绍一下判断中需要用到的一些MC工具和一些变量的定义。

直接用在地图上跑动的人物图像来判断碰撞并不是一个好办法。因为如果直接让人物去碰障碍物，画面上的显示要么是人会挡住障碍物被碰到的部分，要么是障碍物挡住人被碰到的部分，而无论哪一种都是不理想的画面。我们要做的是：在发生遮挡之前就判断好人物下一步运动是否会碰到障碍物而发生重叠遮挡，如果是的话就根本不让人物再继续前进了。

要做到这个判断其实很简单。假设所有人物跑动的动画都封装在一个限定大小的MC里，人物跑动的步长为step。如下图所示：
[attach]10884[/attach][attach]10885[/attach]
我的人物跑动动画每一帧的大小始终都不会超出图中蓝色矩形部分。而红色矩形是一个在各个方向都比蓝色矩形宽一个step长度的矩形（4个顶点被另外的MC挡住了，以后说明）。现在用红色矩形（名为blk）代替实际人物动画来判断与场景中障碍物的碰撞情况就没有问题了。若障碍物碰到了blk，如情况B，人物停止向障碍物的方向运动。如果没有碰到，最极端的情况是A，障碍物刚好与blk擦边。但blk比man宽一个step，下一步人物也只会运动到C位置，也就是障碍物刚好与实际人物动画擦边。这样就避免了碰撞检测中的遮挡问题。实际应用时，将blk放到人物运动动画的一个图层里，并在人物初始化的时候设置blk的visible属性为false就好了。

如上两幅图所示，这里引进了几组新变量，它们的意思解释如下：
假设人物与障碍物碰撞了，并且使用PPCD.getCollisionPoint得到了碰撞边界矩形的中心点（如图B、C中的点和方框所示）：

var pt:Point=PPCD.getCollisionPoint(this.blk, map, mapCon);

复制代码

要知道man在哪个方向、多远距离碰到了障碍，只需要比较man的坐标(x, y)和pt的坐标(pt.x, pt.y)就行了。这里对这两个点的坐标作差：
var dx:Number=pt.x-this.x;
var dy:Number=pt.y-this.y;

使用dx和dy的方便之处在于它们的符号就代表着碰撞发生的方向。为了以后算法的方便，还有两个变量分别保存上一次碰撞时的dx和dy。当没有碰撞时，这两个值将被清零：
var dxl:Number=0;
var dyl:Number=0;

注意，若仅在x轴向做运动时，pt.x最多只会在C图的位置。换句话说，dx的绝对值应该大于等于w，其中w的定义为：
var w:Number=(width-step)/2;
同理也有var h:Number=(height-step)/2;
这在后面判断“擦边”运动时会用到。另外，因为blk放进了man里，所以这里man的width和height属性其实就别是blk的宽和高。

好了，现在开始正题，碰撞检测。

原理很简单：碰撞肯定是由人物向某个方向（这里假定为x负方向，如情况A所示）运动产生的。为了检测方便，先引入两个变量来存放当前人物的运动方向：
var dirxl:int=sign(dirx);
var diryl:int=sign(diry) ;
其中sign(n)是符号函数，n为正返回1，为负返回-1，等于0则返回0。这两个变量也将在没有碰撞时被清零。

既然在这个运动方向碰撞了，则要禁止人物再向该方向运动。对于这里假定的x向就是：
if(dx!=0 && Math.abs(dy)<h){
  停止再向这边运动！
}
之所以要加一句Math.abs(dy)<h是由于下列这样的情况：
[attach]10886[/attach]
如上图，虽然有碰撞点但这时x向并不是真正的有障碍。这种障碍碰到了人物边缘但人物仍可以“擦边”运动的情况只需要做：
if(dx!=0 && Math.abs(dy)>=h){
  if(dirx){
dirxl=sign(dirx);
  }
}
为什么要把运动方向存进dirxl稍后就清楚了。

要让人物在x负向停下来，这里不可以直接做操作man.dirx=0。因为dirx和diry是函数setDir运作的关键，在setDir外随意它们更改会导致setDir不能正常工作。那么这里再引进两个新的局部变量：
var ctrx:uint=1;
var ctry:uint=1;

并将man的位置递增语句改为：
this.x+=dirx*ctrx;
this.y+=diry*ctry;
这样若要停止人物运动，只需要将相应的ctr变量赋值为0就好了。

禁止人物再向该方向运动的办法如下：
dirxl=sign(dirx);
if(dirx*dirxl>0){
  ctrx=0;
}

先将碰撞时人物的运动方向存进dirxl。当人物继续向该方向运动时会使ctrx=0，人物被停止向该方向递增。而当人物改变了运动方向后，ctrx依然为1，人物被允许以dirx递增x位置。这就是为什么特意引进dirxl、diryl的原因：使程序保存造成碰撞的运动方向，并拿它与当前人物的运动方向来对比，进而通过ctrx、ctry决定是否允许人物继续运动。

碰到障碍后仅仅让人物在舞台上停止运动并不是个好主意，这只会让这个RPG游戏的主人公看起来很呆。更好的做法是：让程序能够自动使人物滑离障碍物从而继续前进。有了之前定义的众多变量的帮助，其实这一点太容易办到了：
if(dirx!=0 && diry==0){
  this.y+=-sign(dy)*step;
  if(dy){
diryl=-sign(dy);
  }
}

别忘了之前说过，使用dx和dy的方便之处在于它们的符号就代表着碰撞发生的方向。要滑离障碍物，只需要向dy的反方向走就行了。如果玩家没有手动控制y向移动，则让代码来帮他吧，只是别忘了把y向的运动方向保存进diryl，因为在向y向的运动途中也可能再碰到障碍，这也就带出了逻辑最复杂的地方。

作者: aobject 时间: 2008-11-16 20:25

如下图所示，情况A、B、C都是代表人物向x负方向移动碰到障碍的情况，上面已经讲述过了。而D、E、F则是在x负向被禁止后，玩家手动（擦边运动）或代码滑动人物在y向的位置时可能产生的碰撞情况。
[attach]10887[/attach]
D其实已经解决了解决：若是从手动控制人物在y向“擦边”走得来，y向运动则会在y轴对应的if(dy!=0 && Math.abs(dx)<w)判断里被停止；若是代码自动滑动得来，由于碰撞后dy反号了，代码会再把人物重新向上滑动。而E则是新情况了：手动的话虽然y向有if(dy!=0 && Math.abs(dx)<w)阻止，但此时dx=0！这样会造成禁止x负向运动的判断if(dx!=0 && Math.abs(dy)<h)被跳过。代码的话dx=0，滑动也会被跳过。而F更糟糕：dx和dy都等于0！所以现在得为这两种情况分别添写新处理方案，否则这些碰撞将不被处理，人物将可以穿墙而过！

好在E的dy还不为0，至少y向运动还有if(dy!=0 && Math.abs(dx)<w)阻止，这个判断也正是处理y向上对应的A、B、C情况的代码。由于禁止x向运动的代码被跳过了，这里需要再在这个if里面嵌套个if(dx==0)来补上，这样情况E就解决了：
if(dx==0){
  if(dirxl && Math.abs(dy)<h){
if(dirx*dirxl>0){
   ctrx=0;
} else if(dirx*dirxl<0){
   dyl==100;
   dirxl=0;
   unHit=true;
}
  }
}
其中else语句中的清零是为了防止bug，马上在下一种碰撞情况G里有解释，它对应的情况如下图所示：
[attach]10888[/attach]
要导致dx=0还有一种情况，那就是大图中最后一种情况G：最初向上走然后碰到一个刚好在人物y中轴线上的障碍，或者一个大面积的Y向障碍。这种情况也一并在这个if(dy!=0 && Math.abs(dx)<w)里的if(dx==0)里解决。

如果发生情况G了，虽然dx=0，但人物仍可以在x轴向上左右擦边运动，并且可能碰到障碍，如下图所示：
[attach]10889[/attach]
碰到障碍后的明显变化是dy由原来的>h变为<h，所以这里要处理由G擦边运动而产生的碰撞思路很简单：
1. 若在擦边运动，存运动方向dirxl=sign(dirx);（前文第一次提到擦边时已经这样处理了）；
2. 存当前擦边时的dy值：dyl=dy;
3. 若dy没变，则没有碰撞；若dy变了，撞了，则停止该x轴向运动；
4. 撞了若向相反的x向运动，则认为离开x向障碍，开始了新的擦边运动，dirxl清零；

这里要注意的是，如果反向x运动的话需要清零dirxl，这是因为只要反向走一步就一定没有再碰到了x向障碍了，而继续反向行走则可能遇到新的x向障碍，若不清零dirxl将导致反向x障碍穿墙bug。其中还有的dxl和unHit清零在下面的算法代码里解释。

上面的思路翻译为代码则是下面第二个else中的语句：
if(dx==0){
  if(dirxl && Math.abs(dy)<h){
if(dirx*dirxl>0){
   ctrx=0;
} else if(dirx*dirxl<0){
   dyl==100;
   dirxl=0;
   unHit=true;
}
  } else {

if(dyl==100){// 记录这时的dy
   dyl=dy;
}

if(dy!=dyl){// dy变了，说明x方向也遇到障碍
   if(unHit){// 记录此时x运动方向
      dirxl=sign(dirx);
      unHit=false;
   }

   if(dirx*dirxl>0){// 不可再向该x方向运动
      ctrx=0;
   } else if(dirx*dirxl<0){ // 反向x运动，认为x向没有碰撞了
      dyl=100;
      dirxl=0;
      unHit=true;
   }
}

  }
}

引入unHit是因为碰到x向障碍后dy会变。但是若此时要反x向走离开x向障碍，dy也会变。而只有第一中情况的dy变化需要阻止当前x向运动，所以添加一个unHit来区分这两种情况。否则人物在擦边运动时碰到新障碍就被“黏住”走不掉了。同样要注意的是反x向行走后的清零防止bug。

好了，到这里就只有最后一种情况F没有处理了。其实很简单，因为导致情况F碰撞的x、y运动方向之前一定都已经存在dirxl、diryl里了，这里要做的只是简单的屏蔽，这表现在最后两个if判断：
if(dx==0 && dy==0){
  var ptArr:Array=hitPoints();
  if(ptArr.length==1){
dirxl=-ptArr[0].x;
diryl=-ptArr[0].y;
  }

  if(dirxl==0 && dirx!=0){
dirxl=sign(dirx);
  }
  if(diryl==0 && diry!=0){
diryl=sign(diry);
  }

  if(dirx*dirxl>0){
ctrx=0;
  }
  if(diry*diryl>0){
ctry=0;
  }
}

唯一的例外是下面的情况：
[attach]10890[/attach]
解决这个问题的办法也很简单：倒数第三、第四个if：记录当前运动方向并阻止。

最后需要特别注意的情况是两边都全部被碰到，如下图：
[attach]10891[/attach]
虽然这种情况的得来和判断其实是和情况F一样的，但考虑到这种情况和其它碰撞情况之间的转换以及各种变量清零的麻烦和可能导致的bug，就特意写了一小段新算法来处理。

这种情况的处理思路上也很简单：有3个顶点都被撞到了，那找出剩下一个顶点的方向并只允许朝它的方向运动就好了。这其实就是最开始的代码段
var ptArr:Array=hitPoints();
if(ptArr.length==1){
  dirxl=-ptArr[0].x;
  diryl=-ptArr[0].y;
}
做的事情。而判断各个顶点是否被碰撞借用了挡住红色blk顶点的那4个绿色顶角正方形。hitPoints函数首先找出没有被碰撞的顶点，然后把这个顶点的方向push到一个数组并返回。如上图例子，ptArr就是一个含有一个Point的数组：prArr[0]=(1, -1)。

至此所有的碰撞检测情况就都分析完了。虽然情况繁多但逻辑并不晦涩，循序渐进仔细理清调理就好了。实际的检测代码也并不长。完整的检测代码参见源文件。

作者: aobject 时间: 2008-11-16 20:30

自己先顶一个

作者: kingroy 时间: 2008-11-17 09:48

好东西，谢谢！！

作者: gssbyp 时间: 2008-11-17 11:10 标题: 大哥辛苦了，帮顶

大哥辛苦了，帮顶大哥辛苦了，帮顶

作者: aobject 时间: 2008-11-17 21:40

这种地图碰撞检测不知道是否大家常用的检测方法呢,有经验的兄弟发表几句啊,100多人查看竟只有二位兄弟回复,这学习态度可不行哦

作者: wandenmin520 时间: 2008-11-18 09:04

有点难，不过很好，好好学习下！

作者: houyp2005 时间: 2008-11-18 18:41

顶一个,我也喜欢flash游戏开发,而且自己还做了论坛

作者: dgf1988 时间: 2008-11-18 21:32

哇，好帖，留名哦

作者: wizim 时间: 2008-11-18 23:58

顶！支持！辛苦！！

作者: anky84 时间: 2008-11-19 15:42

很好很强大，我来回帖的，之后再慢慢学习一下。

作者: Aone 时间: 2008-11-19 16:00

好文，顶一下~
做单机RPG不错。

作者: lala 时间: 2008-11-21 09:05

不错不错顶。。。。。。。。。。。。

作者: foxlively 时间: 2008-11-21 09:09

支持啊支持

作者: jare_as3 时间: 2008-11-22 17:02

....好东西...天书...

作者: lixinlixin2008 时间: 2008-11-22 17:08

不错,收藏先......

作者: yoolele 时间: 2008-11-23 21:16 标题: 回复板凳的帖子

学习啊,呵呵 ,我什么时候才有如此技术啊

作者: aobject 时间: 2008-11-23 21:25

原帖由 yoolele 于 2008-11-23 21:16 发表
学习啊,呵呵 ,我什么时候才有如此技术啊

大量的学习,大量实践,坚持不懈,你也能拥有这种技术

作者: 猫天猫地 时间: 2008-11-27 12:04

大哥辛苦了，帮顶大哥辛苦了，帮顶

作者: gd4219 时间: 2008-11-27 21:20

RPG地图里的自动寻径怎么算啊？？？？？
加入不用二唯数组+A*的话

作者: zqsun 时间: 2008-11-28 20:49

辛苦楼主了，学习一下

作者: shell 时间: 2008-11-29 06:57

i also found a GUI.swf in the nami hosting
, i am now want to writing a game like this , this post is really useful for me
, and thx ur sharing !!

作者: 184367426 时间: 2008-12-1 15:24

好东西，真不错

作者: daivi 时间: 2008-12-1 17:01

不错的贴子,收藏用习

作者: showboywlq 时间: 2008-12-1 17:28

太好了，1

，收了先

作者: scabwort 时间: 2008-12-2 14:35

支持啊,真好做物理引擎用着啦,哈哈...

作者: needspeedboy 时间: 2008-12-2 17:03

可以和地图结合试试加上寻址AI

作者: huhu8868 时间: 2008-12-2 20:37

好贴，顶～～～～～～～～～

作者: colinlin 时间: 2008-12-3 16:02

楼主辛苦了，谢谢啦，

作者: lxhdj 时间: 2008-12-6 12:59

呵呵，有段时间没来，帖子被转到这里啦，哈哈哈.. 受宠若惊ing...

目前地图引擎除了A*还没好好实现，其它都差不多了，要不要看更新啊哈哈哈哈... 解压后直接开bleachGame.swf。
源文件非常乱，也没有好好写Docs了，555... 没时间ing...

顺便招募美术，对Bleach有爱的神一样的美术朋友来联系我哇，哈哈哈，争取把这个项目完成，拖了大半年了都。
Bleach Online! MMO RPG!

[ 本帖最后由 lxhdj 于 2008-12-6 13:08 编辑 ]

作者: vladimir 时间: 2008-12-8 11:39

楼主正强哈,已存,学习中!

作者: 猫天猫地 时间: 2008-12-9 17:34

自己先顶一个

作者: bjxyj 时间: 2008-12-16 21:07

很不错.支持一下了.哈哈!!!!!!!!!

作者: energy_v 时间: 2008-12-20 19:29

好帖哦，先顶再看~~~

作者: jianglang 时间: 2008-12-20 20:01

我还以为是源文件呢哎白下了!!

作者: energy_v 时间: 2008-12-20 22:16

好东西，可惜源文件现在不能下了

作者: keiichi 时间: 2009-1-26 21:46

项一个先，坐下来慢慢学习

作者: 小飞 时间: 2009-1-28 16:43

很有用的东东，先收藏啦，慢慢研究

作者: jianren719 时间: 2009-2-5 21:36

貌似很长很强大先顶一个坐下来慢慢看

作者: friendyi 时间: 2009-2-6 14:33

相当不错 ding啊

作者: nicklo 时间: 2009-2-10 14:55

挻详细的的! 学习吸收!

作者: hesaz 时间: 2009-2-12 13:41

好东西，顶

作者: nicklo 时间: 2009-2-16 10:34

这还是需要认真的学习一下!

作者: ebly 时间: 2009-2-18 13:14

非常不错的文章
顶了！！！

作者: tithunter 时间: 2009-2-20 11:43

好强大的帖，谢谢LZ，我也找了好久

作者: as3kajika 时间: 2009-2-25 13:47

嗯嗯~非常支持

作者: kaishuai007 时间: 2009-2-25 18:03

慢慢学习

作者: zcc0511 时间: 2009-2-25 19:11

狂顶哦、。。。。。学习

作者: gogogogogo 时间: 2009-3-3 00:44

好文，顶一下

作者: wolf2999 时间: 2009-3-3 12:18

这个不错。。支持。。。。。

作者: longfengabc 时间: 2009-3-6 16:16

我不说话～

作者: babyzone2004 时间: 2009-3-7 01:29

多谢了。呵呵

作者: 新悦u 时间: 2009-3-10 16:16 标题: 因为一个软件，我们分手了

提示: 作者被禁止或删除内容自动屏蔽

作者: RedSquirrel 时间: 2009-3-11 19:56

好文，顶一下~

作者: shell 时间: 2009-3-12 18:52

堪稱精華的算法!!!

作者: jiangzhilin2009 时间: 2009-3-13 00:00

来学习学习好帖啊

作者: tithunter 时间: 2009-3-13 09:03

好东西啊~~支持

作者: wolf2999 时间: 2009-3-13 16:15

区块游戏开发里面的碰撞好像没楼主这么复杂。

可能是楼主的考虑得比较周到。

作者: bingan 时间: 2009-3-18 14:55

好东东啊,o(∩_∩)o...,正需要呢

作者: jiangzhilin2009 时间: 2009-3-22 10:39

好东西啊经典

作者: sun11086 时间: 2009-3-30 20:45

有点难懂啊，今天了看了一下还是没看明白，主要是键盘控制逻辑那块有些难理解.....有些话有些难理解

作者: 月夜儛 时间: 2009-3-31 11:12

第一次来游戏区看文，就发现好东西了

作者: lengsehuoyan 时间: 2009-3-31 12:59

留名收藏～顶帖～

作者: maloveqiao 时间: 2009-4-3 13:28

好东西，谢谢分享

作者: twtmnm1314 时间: 2009-4-4 15:01

太牛了。学习下。

作者: twtmnm1314 时间: 2009-4-4 21:24

一定要支持下。

作者: fashionweb 时间: 2009-4-9 09:19

严重支持，谢谢楼主

作者: liuzheng 时间: 2009-4-11 23:13

很强大啊!!不错不错

作者: South123 时间: 2009-4-13 16:13

资源啊，顶！不过是个比较庞大的技术问题，有空再看吧。

作者: maloveqiao 时间: 2009-4-22 13:21

好东西，谢谢楼主

作者: icefirefdp 时间: 2009-4-22 15:08

好东西给看给顶

作者: lidan921 时间: 2009-4-29 22:45

很难看懂```

作者: sapphire 时间: 2009-5-10 14:47

哈，我看完了居然没有一点@ @
帅哥的智商都比较高，本人就是一个例子

作者: lihaitao 时间: 2009-5-11 00:02

兄弟辛苦了啊！！

作者: 三脚猫 时间: 2009-5-12 19:36

好帖子学习了

作者: lihaitao 时间: 2009-5-13 17:15

辛苦LZ了，正在学习中

作者: kael 时间: 2009-5-13 18:36

强悍啊,这个不顶还顶什么!!!!!!!!!!!!!!!!!!!!!!!!

作者: 口袋 时间: 2009-6-1 15:58

一定要支持下啊，，，很好

作者: zhyliy 时间: 2009-6-24 16:51

顶！！

作者: fykyx521 时间: 2009-6-25 09:56

回帖，以后容易找到

作者: 猫天猫地 时间: 2009-7-30 13:15

不错

作者: king9981 时间: 2009-8-23 13:25

http://www.xgenstudios.com/play/stickarena
老外闹的

作者: LokooChen 时间: 2009-8-23 23:00

很久以前知道这个检测碰撞的方法。
不过后来越用越少了。
因为这个方法是用bitmap来做检测了，老外贴的那个源func，还能加些边界的检测来加快一下速度。
但到底是用bitmap来检测的。所以速度，其实速度比直接用hitTestPoint要慢。
假设我正在做一飞机的游戏。
如果地图是500X650，左右，里面加上ai，飞弹，飞机，（不算地图动画和上层的云之类的动画），如果用这方法的话，pf9，30-50个共时动的东西，就会明显感觉到卡了。
如果用hitTestPoint，情况会好点，能多20-30个左右。如果ai不太复杂的话，fp9同时有差不多100个东西在动，问题也不太大。
不过这2个方法如果要解决物体以很快的速度穿过某物体的话，要负出很大的代价。
当然用数学方法最好了：），

可惜我数学不行，楼主再来个用数学方法处理碰撞的贴子吧。

想做mmo，就得用数学方法~~。（个人觉得）

作者: yinqikai 时间: 2009-9-18 18:51

大量的学习,大量实践,坚持不懈

作者: cuckoo03 时间: 2009-9-26 14:18

顶！慢慢学习

作者: icekiller 时间: 2009-9-27 21:41

哈哈，不错的文章，希望楼主多多分享些

作者: likyweb 时间: 2009-9-29 15:00

楼主辛苦了，好东西，先顶一下，再学习，，

作者: qingyu 时间: 2009-10-9 08:40

不错...值得收藏

作者: stlanshu 时间: 2009-10-12 15:24

我也来学习学习～～wowo

作者: gjsj005 时间: 2009-10-12 15:53

顶一下。。

作者: ysong789 时间: 2009-10-13 16:03

占个座位

作者: flash_str01 时间: 2009-10-14 19:48

一定要收藏的帖子~~~~

作者: halfmile 时间: 2009-10-14 21:14

很细致，顶一下

作者: traintrackcn 时间: 2009-10-15 12:01

很详细的讲解，谢谢分享

作者: Backham07 时间: 2009-10-28 11:44

我收藏栏不够放了

作者: yangxn 时间: 2009-11-4 16:16

支持楼主！

作者: evajhhot 时间: 2009-11-6 13:54

支持楼主啊

作者: xiaozhichao2000 时间: 2009-11-8 21:19

先收藏，以后有时间再仔细看看：）

作者: yourihua 时间: 2009-11-8 22:26

收藏了，不错

欢迎光临 9RIA.com天地会 - 论坛 (http://bbs.9ria.com/)