有人会问，怎么快速知道到底渲染了多少次了，告诉你吧，游戏左下角有三行数据：
GLverts表示给显卡绘制的顶点数
GLcalls表示代表每一帧中OpenGL指令的调用次数
FPS这个是帧率不多说
主要看第二个“GLcalls”代表每一帧中OpenGL指令的调用次数，这个数字越小，程序的绘制性能就越好。

COCOS2DX 3.0 优化提升渲染速度 Auto-batching

最近在看COCOS2DX 3.0的Auto-batching合批与 Auto Culling动态缩减功能下面就来仔细看看吧：整合好的渲染提速干货:

简介

在游戏的绘制渲染中，往往消耗很多资源和内存，当绘制精灵数量越多，游戏的卡顿会很明显，为了优化和提升渲染效率。Cocos2d-x为我们提供了Auto-batching和SpriteBatchNode。

Auto-batching 意思是Renderer将多次draw的调用打包成一次big Draw 调用。(又名批处理)。

SpriteBatchNode 主要用于批量绘制精灵提高精灵的绘制效率的，需要绘制的精灵数量越多，效果越明显。

Auto-batching

在3.0版本实现了引擎的逻辑代码与渲染代码的分离，实现了Auto Batch与Auto Culling功能。不再推荐使用SpriteBatchNode提高精灵的绘制效率。

Auto-culling的支持，Sprite在绘制时会进行检查，超出屏幕的不会发给渲染。

Auto-batching的渲染流程

现在，一个渲染流程是这样的：

（1）drawScene开始绘制场景

（2）遍历场景的子节点，调用visit函数，递归遍历子节点的子节点，以及子节点的子节点的子节点，以及…

（3）对每一个子节点调用draw函数

（4）初始化QuadCommand对象，这就是渲染命令，会丢到渲染队列里

（5）丢完QuadCommand就完事了，接着就交给渲染逻辑处理了。

（6）是时候轮到渲染逻辑干活干活，遍历渲染命令队列，这时候会有一个变量，用来保存渲染命令里的材质ID，遍历过程中就拿当前渲染命令的材质ID和上一个的材质ID对比，如果发现是一样的，那就不进行渲染，保存一下所需的信息，继续下一个遍历。好，如果这时候发现当前材质ID和上一个材质ID不一样，那就开始渲染，这就算是一个渲染批次了。

（7）因此，如果我们创建了10个材质相同的对象，但是中间夹杂了一个不同材质的对象，假设它们的渲染命令在队列里的顺序是这样的：2个A，3个A，1个B，1个A，2个A，2个A。那么前面5个相同材质的对象A会进行一次渲染，中间的一个不同材质对象B进行一次渲染，后面的5个相同材质的对象A又进行一次渲染。一共会进行三次批渲染。

SpriteBatchNode

它是批处理绘制精灵，主要是用来提高精灵的绘制效率的，需要绘制的精灵数量越多，效果越明显。因为cocos2d-x采用opengl es绘制图片的，opengl es绘制每个精灵都会执行：open-draw-close流程。而SpriteBatchNode是把多个精灵放到一个纹理上，绘制的时候直接统一绘制该texture，不需要单独绘制子节点，这样opengl es绘制的时候变成了：open-draw()-draw()…-draw()-close()，节省了多次open-close的时间。SpriteBatchNode内部封装了一个TextureAtlas(纹理图集，它内部封装了一个Texture2D)和一个Array(用来存储SpriteBatchNode的子节点：单个精灵)。注意：因为绘制的时候只open-close一次，所以SpriteBatchNode对象的所有子节点都必须和它是用同一个texture(同一张图片)。

在addChild的时候会检查子节点纹理的名称跟SpriteBatchNode的是不是一样，如果不一样就会出错。

// check Sprite is using the same texture id

CCASSERT(sprite->getTexture()->getName() == _textureAtlas->getTexture()->getName(),"CCSprite is not using the same texture id");

SpriteBatchNode和SpriteFrameCache结合使用代码示例

必须保证SpriteFrameCache和SpriteBatchNode加载的是同一纹理贴图。

SpriteBatchNode vs. Auto-batching

在3.0版本中提供了新的渲染机制，实现引擎逻辑代码和渲染的分离。该版本依然支持SpriteBatchNode，和以前的版本保持一致。但是不再推荐使用SpriteBatchNode。

Auto-culling的支持，Sprite在绘制时会进行检查，超出屏幕的不会发给渲染。

使用Auto-batching

·需确保精灵对象拥有相同的TextureId(精灵表单spritesheet)；

·确保他们都使用相同的材质和混合功能

·不再把精灵添加SpriteBatchNode上

·避免打乱QuadCommand队列

Auto-batching拥有更好的性能提升。

下面通过代码来分析几种符合Auto-batching使用的情况

1、使用同一图片生成精灵，加到场景中。此种情况最简单，就是重复添加同一个精灵。由于满足Auto-batching的条件。此时的渲染批次为2.(首先，即使我一个精灵也不创建，渲染批次也至少是1,加上刚刚这重复添加的精灵的渲染)

2、使用精灵帧表单，加载生成添加不同的精灵。但是各个精灵的材质都是一样的，满足Auto-batching的条件。此时的渲染批次为2.(首先，即使我一个精灵也不创建，渲染批次也至少是1,加上刚刚这重复添加的精灵的渲染)

在实际使用中推荐使用这种方式。

3、此种情况假设在不同的zOrder下添加不同的精灵，在遍历子节点之前，其实还偷偷做了一件事情，那就是，调用sortAllChildren();函数对子节点进行排序，虽然重复添加不同材质生成的精灵，但是它们的zOrder不一样，根据zOrder，Auto-batching渲染命令被重新排序，根据材质相同加入渲染队列从而降低了渲染次数。

如果注释掉sprite2->setZOrder(1);你会发现渲染批次会升高。

Auto-batching是Cocos2d-x3.0新增的特性，目的是为了取代SpriteBatchNode，完成渲染的批处理，提高绘制效率。

至于它有什么特点，可以看看官方文档，这里主要想探讨Auto-batching一些条件限制，简单地从源码方面去分析。

主要想分析的问题就是：为什么不连续创建的精灵（相同纹理、相同混合函数、没有对shader做什么处理）不能满足Auto-batching的要求？

===========以下是回忆，是我对Auto-batching产生疑惑的过程，可以忽略不看=========

这得从前几天说起（小若：我们不是来听故事的！），我在更改之前SpriteBatchNode的教程，由于Cocos2d-x3.0新增了Auto-batching，于是就不得不把它也加进去。

这一加，不对劲，越写越发现自己对Auto-batching的理解有误，在我的脑海中，只要精灵是使用同一个纹理、没有更改blendFunc、没有更改shader，那么就满足Auto-batching，会自动将这些精灵加入到同一个渲染批次里，优化渲染速度。

可我才刚准备写一个例子，却发现，不对！没有自动批处理。我当时做了这样一个实验，代码如下：

  
  
   
    
     
     /* 创建很多很多个精灵 */ 
      for(inti=0;i<14100;i++) 
      { 
         Sprite*xiaoruo=Sprite::create("sprite0.png"); 
         xiaoruo->setPosition(Point(CCRANDOM_0_1()*480,120+CCRANDOM_0_1()*300)); 
         this->addChild(xiaoruo); 
      
         xiaoruo"sprite1.png"); 
      }

我创建了两组精灵，分别使用sprite0.png和sprite1.png图片，每组14100个（小若：为什么非得是14100，为什么不能是14000？你让我们这些强迫症的人怎么办？！）。

按照我对Auto-batching的误解，这两组精灵应该各自都能满足，都能分别作为一组批处理进行渲染。然而，运行结果如下：

GLcalls（渲染批次）竟然是16425次？这和想象中的完全不一样，不是应该是个位数么？

这颠覆了我对Auto-batching的理解，于是，我又做了一些实验，发现了一些谬论，但结果是好的，因为我知道，我对Auto-batching的理解一直都是错的。

关于我做的那几个实现，大家可以看看这个帖子：Cocos2d-x3.0Auto-batching三个小实验

由于是使用Windows平台做测试的，然后我的电脑配置比较高（小若：这是在炫耀的意思么？敢亮出你的配置吗？），所以帧率不能作为参考。

总之，那个帖子得出的疑问是：为什么不连续创建的精灵（相同纹理、相同混合函数、没有对shader做什么处理）不能满足Auto-batching的要求？

一定是我对Auto-batching产生了误解，它应该还有一些我不知道的限制。

好，既然知道我对Auto-batching产生了误解了，我当然就要再一次去看官方文档了，首先是中文文档：

https://github.com/chukong/cocos-docs/blob/master/manual/framework/native/v3/auto-batching/zh.md

反复看了好几次，不行，完全找不到能对这个问题有帮助的内容，但是我找不到英文文档。

终于还是找到了，它并不是真正的文档，只是一些计划路线，但是对这个问题也很有帮助，标题是《Cocos2d(v.3.0)renderingpipelineroadmap》：

https://docs.google.com/document/d/17zjC55vbP_PYTftTZEuvqXuMb9PbYNxRFu0EGTULPK8/edit#heading=h.dii2kgdfqgcp

对着这份文档看，以及调试源码，总算弄明白这个问题了。

简单地说，要绘制的精灵（应该说是Node）先存放到队列里，然后由专门的渲染逻辑来渲染。对于队列中的精灵，一个个取出来（其实存取的不是精灵，这里先简单这么理解），发现材质一样的话（相同纹理、相同混合函数、相同shader），就放到一个批次里，如果发现不同的材质，则开始绘制之前连续的那些精灵（都在一个批次里）。然后继续取，继续判断材质。

如果相同材质的精灵，中间间隔了不同材质的精灵，那也没法在同一个批次里渲染。

这就是那个问题的答案：为什么不连续创建的精灵（相同纹理、相同混合函数、相同shader）不能满足Auto-batching的要求，因为只要中间有不同材质的渲染对象，就会中断，会先把之前连续的相同材质的对象进行批渲染。

========================以上是回忆，回忆结束========================

好了，上面是回忆的过程，并且已经有了大致的结论，现在正式来用代码解释。

笨木头花心贡献，啥？花心？不呢，是用心~

转载请注明，原文地址：http://www.benmutou.com/blog/archives/1006

文章来源：笨木头与游戏开发

渲染流程

现在，一个渲染流程是这样的：

（1）drawScene开始绘制场景

（2）遍历场景的子节点，调用visit函数，递归遍历子节点的子节点，以及子节点的子节点的子节点，以及…
（小若：够了！给我停！）

（3）对每一个子节点调用draw函数

（4）初始化QuadCommand对象，这就是渲染命令，会丢到渲染队列里

（5）丢完QuadCommand就完事了，接着就交给渲染逻辑处理了。

（7）是时候轮到渲染逻辑干活干活，遍历渲染命令队列，这时候会有一个变量，用来保存渲染命令里的材质ID，遍历过程中就拿当前渲染命令的材质ID和上一个的材质ID对比，如果发现是一样的，那就不进行渲染，保存一下所需的信息，继续下一个遍历。好，如果这时候发现当前材质ID和上一个材质ID不一样，那就开始渲染，这就算是一个渲染批次了。

看官方的一张图就完全明白了：

（8）因此，如果我们创建了10个材质相同的对象，但是中间夹杂了一个不同材质的对象，假设它们的渲染命令在队列里的顺序是这样的：2个A，3个A，1个B，1个A，2个A，2个A。那么前面5个相同材质的对象A会进行一次渲染，中间的一个不同材质对象B进行一次渲染，后面的5个相同材质的对象A又进行一次渲染。一共会进行三次批渲染。

（小若：突然发现，第6条哪去了啊？被你吃了吗）

这么一说，太含糊了，我们再来一次，用代码来罗列。

1.drawScene开始绘制场景

首先是开始，简单点，看代码：

voidDisplayLinkDirector::mainLoop() 
     { 
     if(_purgeDirectorInNextLoop) 
         _purgeDirectorInNextLoop=false; 
         purgeDirector(); 
      } 
     elseif(!_invalid) 
         drawScene(); 
        
        // release the objects 
         PoolManager::getInstance()->getCurrentPool()->clear(); 
     }

if(_runningScene)

_runningScene->visit(_renderer,identity,false);

_eventDispatcher->dispatchEvent(_eventAfterVisit);

没错，调用visit函数遍历场景的所有子节点（包括子节点的子节点，一直递归），然后做一些操作。

3.对每一个子节点调用draw函数

当然，我们最终关心的是，调用这些子节点的draw函数。

voidSprite::draw(Renderer*renderer,constkmMat4&transform,booltransformUpdated)

// Don't do calculate the culling if the transform was not updated

_insideBounds=transformUpdated?isInsideBounds():_insideBounds;

if(_insideBounds)

_quadCommand.init(_globalZOrder,_texture->getName(),_shaderProgram,_blendFunc,&_quad,1,transform);

renderer->addCommand(&_quadCommand);

我删掉了一些吓人的代码。

4.初始化QuadCommand对象，这就是渲染命令

上面的代码就是重点了，初始化_quadCommand对象，这就是QuadCommand，渲染命令。

其实渲染命令不仅仅只有QuadCommand，还有其他的，比如CustomCommand，自定义渲染命令，顾名思义，就是我们用户自己定制的命令，由于我没有使用过，就不介绍了。

然后，接着就调用addCommand函数将渲染命令加入队列。

这里有一点，也很重要，由于渲染命令有好几种，所以addCommand的时候，其实是会根据不同的命令类型把渲染命令添加到不同的队列。本文只想针对QuadCommand，所以就忽略这一点，假设我们的所有命令都是QuadCommand。

5.丢完QuadCommand就完事了

draw函数执行完，就轮到渲染逻辑干活了。

6.开始渲染

轮到渲染逻辑干活了，之前介绍了，渲染命令有好几种，如果我没有理解错误的话，只有QuadCommand才能参与自动批处理，因此，这里会对渲染命令进行筛选，发现是QuadCommand类型的命令就保存到一个队列里。如代码：

if(commandType==RenderCommand::Type::QUAD_COMMAND)

{

autocmdstatic_cast<QuadCommand*>(command);

_batchedQuadCommands.push_back(cmd);

}

==RenderCommand::Type::CUSTOM_COMMAND)

{}

==RenderCommand::Type::BATCH_COMMAND)

==RenderCommand::Type::GROUP_COMMAND)

else

{}

voidQuadCommand::init(floatglobalOrder,GLuint textureID,GLProgram*shader,BlendFunc blendType,V3F_C4B_T2F_Quad*quad,ssize_t quadCount,constkmMat4&mv)

_globalOrder=globalOrder;

_textureID=textureID;

_blendType=blendType;

_shader=shader;

_quadsCount=quadCount;

_quads=quad;

_mv=mv;

_dirtytrue;

generateMaterialID();

init函数里最后调用了generateMaterialID函数，这个函数就是关键。（小若：够了你，什么都是关键，关键个毛线啊）

voidQuadCommand::generateMaterialID()

if(_dirty)

//Generate Material ID

//TODO fix blend id generation

intblendIDif(_blendType==BlendFunc::DISABLE)

blendID==BlendFunc::ALPHA_PREMULTIPLIED)

=1;

==BlendFunc::ALPHA_NON_PREMULTIPLIED)

=2;

==BlendFunc::ADDITIVE)

=3;

=4;

// convert program id,texture id and blend id into byte array

charbyteArray[12];

convertIntToByteArray(_shader->getProgram(),byteArray);

convertIntToByteArray(blendID,byteArray+4);

convertIntToByteArray(_textureID,byteArray+8);

_materialID=XXH32(byteArray,12,0);

_dirty 看到没？~我们的材质ID（_materialID）最终是要由shader（_shader->getProgram()）、混合函数ID（blendID）、纹理ID（_textureID）组成的啊喂！所以这三样东西如果有谁不一样的话，那就无法生成相同的材质ID，也就无法在同一个批次里进行渲染了。

_blendType就是我们的BlendFunc混合函数，注意一下，这里所说的相同的混合函数，并不是指要完全相同的值，
其实只是相同类型，看看if else的那几个判断就知道了，最后需要的只是blendID这个值。

当然，至于为什么要这样生成材质ID，我就没有去深究了，我只是个写游戏的，引擎底层，还是交给Cocos2d-x团队的人吧（邪恶）。

8.怎样才能让相同材质的对象的渲染命令连续排列？

不连续的渲染命令，即使材质ID相同也没有用，那，我们应该怎么让这些家伙连续起来呢？

这个问题好办，还记得场景绘制的时候会遍历所有子节点吧？

在遍历子节点之前，其实还偷偷做了一件事情，那就是，调用sortAllChildren();函数对子节点进行排序，对比的规则是：

boolnodeComparisonLess(Node*n1,Node*n2)

return(n1->getLocalZOrder()<n2->getLocalZOrder()||

(n1-==n2->getLocalZOrder()&&n1->getOrderOfArrival()>getOrderOfArrival())

);

这样创建的精灵肯定就没法连续了，因为sprite0.png的精灵和sprite1.png的精灵是不断间隔着创建的，没有连续。而且它们默认的localZOrder都是0，所以排序不起效。

那么，稍微改改就好了，如下：

>addChild(xiaoruo,1); 
     2); 
      只是给精灵分别指定了localZOrder值，这样在排序的时候sprite0.png的精灵就会在一起，同样，sprite1.png的精灵也会在一起。 
  运行结果，来一个很壮观的截图： 
  渲染批次是5，等等！为什么是5？为什么不是2？ 
  9. 渲染队列存储上限 
 
 继续回答刚刚的问题，图中的渲染批次是5，为什么是5？为什么不是2？ 
  首先，即使我一个精灵也不创建，渲染批次也至少是1。 
  那么，我创建了两组材质ID相同的精灵，理论上GL calls应该是3，为什么是5？ 
  这个也很简单，因为渲染队列最大只存放10922个渲染命令，注意，是“只存放”而不是“只能存放”，这个只是在代码里做的限制。 
  当渲染队列（指的是Render类的成员变量：std::vector<QuadCommand*> _batchedQuadCommands; ，之前有讲到）存放的渲染命令大于10922时，就会自动进行一次渲染操作， 
  把队列里的渲染命令处理掉。 
  因此，我创建了2组精灵，每组14100个，已经超过了10922的范围，所以，即使这2组精灵各自都是相同的材质，但也不得不被分成2次进行渲染，于是，这2组精灵共进行了4次渲染操作。 
  再加上GL calls默认就有1（为什么默认会有一次，我就没有去研究了），那么，就是5次了。 
  话又说回来了，谁家的游戏那么夸张，要创建28200个精灵啊！这样那些跑分8000左右的手机怎么办啊，我在自己手机里试过了，帧率是60！没错，是60，已经太慢了无法正确计算了。因为每一帧的渲染消耗的时间是2秒多！ 
  一帧就消耗2秒多，太刺激了。 
  嗯，跑题了。 
  结束语 
  好了，关于Auto-batching的探索之旅总算是结束了。 
  我对OpenGL的东西还真不太懂，所以，有可能在研究代码的时候有一些东西被我忽略了，或者误解了，如果文章有错误的地方，那…你来打我啊（别，开玩笑的）。

COCOS2DX 3.0 优化提升渲染速度 Auto-batching

渲染流程

猜你在找的Cocos2d-x相关文章