Hi,
I did performance comparison between cocos2d-x and Starling(the GPU accelerated flash AS3 engine). Project files are attached at the end of this message.
Here are the numbers:
1 sprite repeatedly rendered on the screen. Test hardware:iPod touch 4
I don’t know Starling specifically but this seems like an issue with the number of draw calls being made. Not knowing the details of Starling it’s possibly performing some behind the scenes batching of your sprites where it can draw many in a single draw call.
In Cocos2d-x by default every CCSprite gets an individual draw call. If you want batching behaviour you should look into CCSpriteBatchNode, this takes over drawing of it’s children (who must all be CCSprites) and draws everything in one call. This tends to be much better for performance. All the sprites in a batch node need to use the same texture (actually the texture is a property of the batch node). I think if you were to change your Cocos2d-x test to use this then it would consistently beat Starling.
Fakhir Shaheen, I've read your code.Stuart McGaw is right, you should use CCSpriteBatchNode to reduce the draw call, instead of one sprite for each class Particle, which will cause lots of draw calls.
Well, I’ve sent you a pull request https://github.com/fakhirsh/DaisyMark-cc2dx/pull/1 The CCBatchNode hasn’t been used correctly, as I wrote in the pull request.
To be honest, even if Ricardo Quesada improved the API set of batch node in v2.x, it’s still a bit confusing to users.
In the previous code, the error points of using CCBatchNode are:
# CCBatchNode is created from daisy-texture.png, while sprites are created from daisy.png. There’s no relationship between sprites and batchNode in your code.
# You added both batchNode and sprites as children of parent node, while the correct usage is to
## parent~~>addChild
## batchNode~~>addChild(sprite)
* NOTE: This line breaks the batchNode optimisation: parent->addChild(sprite)
I increased the particle number from 700 to 2000, batchNode speed up the rendering correctly on my ipad2. You can have a try.
And you’ve noticed the numbers in the bottom-left corners. Their meanings are:
1 <--- How many times of draw calls in one frame
0.016 <--- How long (in seconds) per frame
59.8 <--- FPS
The draw call is 1 if you use batch node properly here, while it will equal to DaisyTest::numParticles if the batch node doesn’t take its job.
OK, I built a 2dx version of DaisyMark, which is attached in this post. Comparing to the Adobe AIR version in your dropbox, the performances on my mobiel phone are
* Device: Galaxy Nexus
* Android Version: 4.2.1
* Particle number: 1000
* Using test case 1, scale and opacity are disabled
* DaisyMark with Adobe AIR and starling: 12~14 FPS,
* DaisyMark with Cocos2d-x v2.1.1: 32~34 FPS
Sorry I couldn’t pull your request, i am new to git
I just modified the code. Now it is using batching properly:
@
batch->addChild(p->sprite);
@
Test device: iPod touch 4
On the device there is now only 1 draw call even for 3000 sprites. NO significant performance gain at all (just an increase of few FPS). It is still slower than Daisy Mark .
PS: Did you compile starling AIR version DaisyMark using “Flash builder —> Project —> export release build (AppStore)” ?
Sorry I couldn’t pull your request, i am new to git
Well, use my repo directly: https://github.com/walzer/DaisyMark-cc2dx/tree/multi-platform-cpp-and-js
I also rewrote a version in cocos2d js, it still have higher performance than starling on Galaxy Nexus.
If you want to build it, just put cocos2d-x/project/ directory, cocos2d-x/project/DaisyMark-cocos2djs and cocos2d-x/project/DaisyMark-cocos2dx
You usage still seems to be incorrect. You may use a big texture in particle.