吐槽下cocos2d-x 3.x的自动裁剪

吐槽这个自动裁剪,关于性能优化方面,没有哪种策略能做到在任何情景下皆最优,希望能把裁剪策略做为一个可拆卸(自定义)的方式,提供给开发者选择裁剪策略的权利!
目前的裁剪算法是基于图素树遍历裁剪每一个,这种最简单的遍历裁剪算法对于一般的休闲游戏来说没有问题,但对于规模大点并每贞移动的场景来说,简直是灾难,就举个极端点的例子吧,假设做的是赛车游戏,游戏地图很大,是多种titile拼接的,假设1屏幕的小快数量是20*10,上面还会有很多物件,如果什么都不做,使用引擎自带的自动裁剪,贞速率会成为一个灾难。 所以必须使用更高效的裁剪算法,如四叉树、基于视口矩形的快速裁剪算法,现在问题来了,在做好裁剪后,最终已经经过新算法的确认在视口画出的元素,还要经过这个函数再检测一遍
bool Renderer::checkVisibility(const Mat4 &transform, const Size &size)
{
auto scene = Director::getInstance()->getRunningScene();
// only cull the default camera. The culling algorithm is valid for default camera.
if (scene && scene->_defaultCamera != Camera::getVisitingCamera())
return true;

// half size of the screen
Size screen_half = Director::getInstance()->getWinSize();
screen_half.width /= 2;
screen_half.height /= 2;


float hSizeX = size.width/2;
float hSizeY = size.height/2;


Vec4 v4world, v4local;
v4local.set(hSizeX, hSizeY, 0, 1);
transform.transformVector(v4local, &v4world);


// center of screen is (0,0)
v4world.x -= screen_half.width;
v4world.y -= screen_half.height;


// convert content size to world coordinates
float wshw = std::max(fabsf(hSizeX * transform.m + hSizeY * transform.m), fabsf(hSizeX * transform.m - hSizeY * transform.m));
float wshh = std::max(fabsf(hSizeX * transform.m + hSizeY * transform.m), fabsf(hSizeX * transform.m - hSizeY * transform.m));


// compare if it in the positive quadrant of the screen
float tmpx = (fabsf(v4world.x)-wshw);
float tmpy = (fabsf(v4world.y)-wshh);
bool ret = (tmpx < screen_half.width && tmpy < screen_half.height);


return ret;

}

200遍啊200遍!

明白你的意思。

能否帮忙提供一个由于auto-culling导致的严重影响性能,如果移除auto-culling性能明显提升的测试例

我会推动这个问题的修改。

十分感谢

其实楼主可以通过移除和添加的方式,先把所有对象缓存起来,通过四叉树判断是否在显示区域,然后移除和添加对象到地图上,移除和添加前先判断是否在地图上。
我想移除和添加应该比较快

https://github.com/cocos2d/cocos2d-x/issues/9962
添加任务用于方便关闭auto culling。

我的意思其实就是一个sprite已经经过逻辑确认是一定显示的,还是要经过上边的函数做多余的二次检测,几百个sprite时也是一样的,几百次多余的可视检测可能对性能不会有太大的影响,但毕竟还是有影响,如果加个开关就好了

单看上面的算法,运算量很少,影响非常小。
你没看看auto batch draw 几K上w的运算才叫多,粒子精灵都跑没事!
不过,有个开关更加好,因为一般情况下,大部分设计 游戏时候,元素都
会多数在屏内. 没必要增加多一倍的运算