cocos2dx 多边形怎么创
发布网友
发布时间：2022-04-24 14:07
共1个回答
热心网友
时间：2022-04-11 21:36
通过观察Debug信息GL verts 3000+，可以感觉到帧数过低的问题与此相关--很显然，屏幕显示的图形的复杂度直觉上不应有这样多的顶点数，这个现象是不正常的。在nexus5上跑云雾大神的demo，只要在屏幕上滑动手指，帧数就会掉到20帧以下。即使我们将初始化中的多边形减少到一个，例如：
其结果是GL verts仍然有800多
此时场景中顶点数合理值应该在270-280左右，现在这个数目明显是不合理的（此截图由于是在模拟器中运行，最下方的帧数没有参考意义）
当场景中只有一个多边形参与视觉范围计算时，可以看到帧数回升到了60帧，由此可以确认问题确实与顶点数量异常相关，那么到底是什么原因引发了顶点数量异常呢？经过分析，如果我们将这一段代码注释掉，运行会有很大改善。
上面这段代码的本意是在计算出的视觉范围周围加上一些虚影，从而产生类似半影的视觉效果。但是实际上重复进行了10次视觉范围计算，这么做的计算代价实在是太高了。我们的游戏中不需要半影效果，所以注释掉这段代码， GL verts立刻减少到原来的三分之一，在nexus5上demo也可以满60帧运行了。如果需要半影效果但是又不想自己去实现，这里angle+=(M_PI*2)/10的10可以更改为5以下，在nexus5运行上大致可以保证30帧以上，这样对于2d游戏来说是比较合理的。实际上为了实现半影效果，可以有更高效的方式，一种思路是在计算得出交点后对交点按照与发射点之间直线的斜率进行排序，从而得出视觉范围最"外"侧的交点，再由发射点发出更加靠"外"的几条射线进行相交测试，理论可以在一次计算中，尽可能少添加三角面，实现相同的效果。
GL verts代表的顶点数增加本身并不一定会引发帧数降低，实际上顶点数过多所造成的直接影响是对内存的浪费。真正引发帧数降低的是顶点数过多背后所隐含的重复计算造成的计算瓶颈。这里引起了另一个思考，为什么在注释掉上述代码后,GL verts仍有700左右呢？让我们不妨做个实验。将demo中update方法内的代码全部注释掉，然后添加如下代码：
其中dt是update方法的参数，可以看到：
将绘制过程简化后可以得出DrawNode正常使用时顶点数就是700左右。
上面循环中的73*3是半影迭代次数为2，并注释掉以下这两段代码后，通过程序断点观察demo中实际的三角面数。
demo中drawTriangle方法调用的次数就是73*3次（一次本影，两次半影，每次均绘制了73个三角形）。再加上场景中有两个精灵图像，每个有4个顶点，计算后可以知道场景中应当有73*3*3+4*2=665个顶点。但是如果我们看一下DrawNode的实现，会知道在调用了clear方法后，在下一帧cocos会做一些清理工作，因此673这个数字是"合理"的，从另一方面说明了DrawNode用于可视范围绘制时优化的一些可能，首先如果用三角链取代直接绘制三角形，可能大幅降低顶点数量。其次，类似问题中顶点数量变化不大而位置发生变化的，可以考虑使用一个顶点池，消除频繁的内存分配。这些不在本文范围内，以后有机会的话可以详细解释一下这些内容。
角色的移动动画是是游戏实现过程中另一个大量消耗时间的技术点，对于这个问题我们考虑了多种方案，争论的焦点在于是将双脚各自作为处理的对象还是将脚步移动整体作为处理对象。最终确定使用前一方案后，又花了大量时间去编码解决动画的细节，例如双脚在移动中转向的效果处理，双脚所代表的角色的实际位置的确定，与光源位置关系等。作为游戏中的主角，消耗一定时间去完善是有必要的，在实现过程中我们还加入了通过脚印形状区分角色的想法。
