Draw Calls are more than expected (Bitmap fonts are not batched!)

cocos2d-x
#1

I have a scene where I draw different Sprites and TextBMFonts and so on. In that scene I use 2 spritesheets and one Bitmap Font in order to reduce the draw calls like this:

SpriteFrameCache::getInstance()->addSpriteFramesWithFile("gfx/1.plist");
SpriteFrameCache::getInstance()->addSpriteFramesWithFile("gfx/2.plist");

auto sprite = Sprite::createWithSpriteFrameName("fileName");
auto text = TextBMFont::create("999", BmpFont.fnt);

But my draw calls are 13.

As much as I know all the images that are in one spritesheet are being rendered with one draw call with automatic batching implemented in cocos2d-x 3. How can I have more than 3 draw calls? Also, I guess, what is not rendered on the screen does not add a draw call, correct? (I use cocos2d-x 3.2).

P.S. Before optimization, I had 13 draw calls but used ui::Text instead of ui::TextBMFont. But, surprisingly, 13 draw calls are retained even if I have 4 Texts and I have changed them to be bitmap texts. How can all this be explained?

Problem :: Draw calls for Labels [3.0]
#2

I have reduced draw calls to 4 as it is in the image below just by removing all TextBMFont from the screen. Hence, the most problematic are text labels. Why those are not batched?

Batching CCLabelBMFont
Renderer doesn't batch multiple labels using same bitmap font
#3

Yea, Iā€™ve see this problem too, working on a solution for this.

#4

@nite thanks! Would it be included into cocos2d-x 3.3 version, or we should wait for 3.4?

#5

Iā€™ll try to make it to 3.4

#6

Great, thanks @nite!

#7

If you are going to fix this, you should also look into other sprite-sheet related situations that might need batching. Like bone-rigged characters(multiple sprites,one sprite sheet) or bigger tile maps, etc.

They all should have 1 draw call due to batching and sprite sheet usage.

#8

Yea, definitely they should, can you create issue for those? It will notify other developers so maybe we can fix/improve those faster.

#9

@nite I have created this issue: https://github.com/cocos2d/cocos2d-x/issues/9905 @Kiori please add one more issue for your case. I have never used bone-rigged characters, hence I prefer not to formulate the issue. Could you please do that for us?

#10

@naghekyan
Thanks, I was actually going to create that issue myself, but iā€™ve been ultra busy lately.
Iā€™ll get at it this weekend, try a few use cases and see how many similar issues i can find so this situation is resolved engine-wide.

#11

@nite, I made a comprehensive analysis that complements what @naghekyan had posted/requested.

Here is my link to it:
https://github.com/cocos2d/cocos2d-x/issues/9925

Please let me know if I made any mistakes. I believe my issue was spot on, but Iā€™m not a cocos expert, Iā€™m still learning the engine quite frankly.

So far its been great.

#12

Thanks @Kiori

#13

@nite btw later on i realized that ccstudio has a built-in spritesheet maker, that could be used by the engine to patch things together before runtime. reducing the DCalls to 1.
If the UI elements were handled differently that is, as Images I mean, instead of each being their own weird thing.

Another weird thing is ā€œlabelsā€ have an ā€˜animationā€™ check in their properties, god knows what thatā€™s for, much like the ā€˜frame eventā€™ in advancedā€¦ it would be great if the animation check allowed you to choose how the text is displayed, or if you could overall easily animate the GUI, size, rotation, sprite switching, i mean the system is there(the animation editor), you guys just have to put everything together as one piece and make it easier to use/see.

In a very short time cocos studio -has- come a long way. Iā€™ve used Unity for quite some time, and frankly so far i like the direction cocos is taking a lot more. Specially with easy c++ on the side.

Maybe the studio could take that into account, allow you to add minor properties/script additional code to whatever nodes/etc, there in the editor, so when you finally go to edit mode(the IDE), most of your code is already done/pre-built.
Perhaps there is a better way of doing this, but its worth pointing out that c++(or lua/js for that matter) is great and has to be a part of the studio.

UI handling is very important, how text is rendered(fast displays, or letter by letter, or parts at once, but not all, etc.), like the another poster said ā€˜localizationā€™ also, all these things are possibilities that with a little bit of work the system(engine+studio) can offer out of the box, through GUI interfaces, streamlining production.

Also the animation system needs some improvements, but i guess the devs are aware of that given how fantastic it already is, so maybe iā€™ll make another issue with suggestions there, or maybe iā€™ll just wait.

Thanks again.

#14

I am using only cocos2d-x, though I am familiar with Unity. It would be nice to know in what criteria Unity failed? I know it is a good developed and nice system, very handy for fast development for which the cocos2d-x still needs a path to go. It is based on Entity Component Systems, which is also a big advantage, as I have adapted Artemis to work with cocos2d-x. ECS is the true game architecture and BTW Unreal Engine is also ECS based. What you didnā€™t like in Unity that was better in cocos2d-x (of course, if you are not just a fun of C++ language :smile: )? For me there are 2 criteria the cocos2d-x wins - it is open source/free, and it is in C++ that gives the most freedom/flexibility/speed. I guess, in the rest of nominations Unity wins, right?

#15

Well, for starter lets just say Donā€™t mind me, Iā€™m just a nobody, who works nowhere, knows nothing, and just talks random crazy smack that should be ignored by most ppl.

That said,
since you asked, let me start with this.
One of the best and i mean Best 2d engineers i know(this guys is responsible for tools millions of ppl use) said something about Unity a few months back that i canā€™t forget. Heā€™s words were something like:
ā€˜Unity is just a toy engine, nothing ever really works, it doesnt have feature it has gimmicks, every time you do something a bit more complex, it bugs out on you, and when you try to go around it, oh yeah more bugs. And they wont fix it either, truth is they donā€™t really care, they are not going to give us what we need, and they never listen.ā€™

You need some serious experience to understand what he was saying, truth is that the component system you talked about is not relevant. Its a ā€˜featureā€™ for your eyes, that mostly just attracts attention and has some serious performance problems under unity(like anything). Most of Unityā€™s features are not relevant, they only attract newbs and ppl that donā€™t care about performance. Why do you think every major company makes their own solution, if these engines are so ā€˜greatā€™?

Also c# is utter trash, being tied to .net is just a very bad idea, and like said above, they never listen, ever. People have asked for c++ for a while, they did nothing, actually the real dev community asks for a lot of things and they plain out ignore it.

They are in it for the money, Unity is heavily over priced, for what it offers. I have never seen a professional in the industry not bash it. Also, anything more sophisticated that you want to make will require either months/weeks of coding, or $$$ for your latest asset, which in the end becomes a very investment for an engine you donā€™t own.

2D for instance is a major second citizen in Unity, there is no making 2D games unless you bought something called 2DToolkit, seriously. And thatā€™s -not going to change.
I could go on but this is already a rant so iā€™ll stop here.

Unity can be of use in some situations, provided you donā€™t have a more optimal/performant in-house solutionā€¦

Cocos on the other hand has much, much better performance, its OSS(source access), and the cocos devs never say or do dumb things, clearly they are moving the engine in a very good direction. Plus, frankly, the creator of cocos2d is someone you should respect, he is a great guy and very smart.

For me, performance and source access with, thank god, c++ are the top reasons on my list for -any- engine, thatā€™s just too good to be true.

On a side note, i spent hours on cocos studio this week end, and quite frankly-> its awesome already.
It has a lot of great features, their animation system is already pretty good(check it out if you havent), they have built-in sprite-sheet maker, and overall the layout for a solid future is there.
I think chukong is going to take cc2d to the top.

Its not that hard really, if they make cocos studio a top priority, and also add some of the engine redesigns that iā€™m seeing discussed in the dev forums.(like multi-api solutions)
They can have a set of tools that are just as friendly as game maker, for newbs, but also leverages Lua, -and c++ for more advanced devs.
Cocos can -easily become the de-facto standard for 2d and maybe even good 3D games, they will make big bucks off of it.

Truly, game maker is terrible for anyone who wants depth, Unity is bloated, over priced, and misguided. The bottom line is Cocos has very little competition if youā€™re honest with it.

Iā€™m not gonna comment on Unreal btw, Epic is a terrible company, unreal4 is a very heavy engine, thatā€™s all Iā€™m going to say.

I dont really believe Cocos is the top engine now though, it has a long way to go, but at least it is going there. Oh and donā€™t get dragged by the gfx showdown these ā€˜otherā€™ engines have. If you had the team and the knowledge to make an AAA game, you would develop your own solution, period.

So Cocoā€™s market is good 3D games and Grand 2D games, they donā€™t need to aim any higher.
They need to fully integrate and improve the engine/workflow thatā€™s all.
I believe in 1-2 years Cocos will be the top set of tools out there, specially for indies.(which includes small teams that work for big studios on contracts)

I did a test once a while back running 3000 units on the screen, unity nearly crashed, cocos handled it fine. But thatā€™s another storyā€¦

Good luck with your projects!

#16

@Kiori thanks for your explanation. Was nice to know the opinion you have posted. BTW @nite today I have found one more problem that seems to me very strange. I have a big game world with lots of sprites that are in fixed positions from the begging of the game. The game character can go back and forth in the game world. And as I remember according to the new rendering engine implemented in cocos2d-x 3 those sprites that are out of the screen visible size draw calls are not issued to OpenGL, right? It is like they are not rendered. Here I refer to Auto Culling (A check will be done for each node: If the AABB of the node is outside the frustum, then no Commands will be submitted to the RenderQueue.), So I was kind of calm on adding so many sprites to my game at once. Today I have added lots of particles effects as obstacles along the game world as well. And the result is that I have enormous number of GL vertices and FPS dropped down dramatically. I have more than 600K GL verts, 24 GL calls, and 5 FPS. I have checked again there is no batching for the particle systems either. But I wonder if I have 500 particle systems placed in the world (also hundreds of sprites ) but they are not visible all together - only one or two are visible simultaneously, then why I have so many GL vertices in my game? Where is Auto Culling?

#17

@nite I know very soon 3.4 will be released. Is this batching included? Do you have any news?

#18

Yes, working on it alone with other things.

2 Likes
#19

That is great! Thank you :smile:

#20

Sorry just a heads up, it probably canā€™t make into 3.4 because itā€™s very close to release and donā€™t have time to properly test it. It will hopefully make it to the future release.

There are a lot to test, the most thing is that I need to test if the cpu cost of batching out weights the gain of 1 draw call. because currently cocos2d-x uses more CPU than GPU.