Maybe this won’t relate to cocos2d-x 3.0 engine, but cocostudio need to be improved. Especially, the document and tutorial using cocostudio with cocos2d-x
I think the problem with plugin-x is that it is in a git submodule so it gets less attention.
The structure is fine. I’ve implemented both Android and IOS IAP’s for it for everyone to use
@SonarSystems I think we need tests/cpp-tests to have plugin examples like it has spine etc.
That should fix the problem with it.
The biggest problem I have with cocos2d-x @walzer is the folder structure.
I want to make packages for linux and win via pacman and for mac via homebrew.
For example look at something like SDL. the includes are in an include folder so we get
/usr/lib/libSDL.a
/usr/include/SDL.h
How am I supposed to create an installable package with cocos with the current structure?
The headers and the source files are all using different path levels in the tree.
Social Integration is a must these days as it maintains the sporting spirit of the gamers to have their online leaderboard on facebook, share their scores online and save their game level achievements even if they uninstall the app.
When they will install it later on, they dont have to play all long to get to what they have already achieved.
I had a quick glance at the comments and it seems they all are related to adding features and bells and whistles.
Have anyone taken a look at the source code? I had and I’m disappointed: it’s not optimized and has stupid errors which affect performance.
For instance, let’s take a look at void Sprite::updateTransform(void)
Why on Earth do you copy those matrices? I changed Mat4 to Mat4& and utilization of Mat4 copy constructor dropped from 9% to 2.5%. Pretty easy, huh?
The same problem with Size size = _rect.size; (from 8% to ~0%)
This was a simple example. But there are lots of other places which require refactoring and optimization. For instance, there are too many dynamic_casts. One of which is in Sprite::setDirtyRecursively Is it really needed there? Can’t you just move _recursiveDirty to the Node class and get rid of dynamic_cast at all?
So my request is to pay more attention to performance and the factors affecting it.
Try modify the engine with: void Director::popScene(const std::function<void(Scene* &)>& callback)
{
CCASSERT(_runningScene != nullptr, “running scene should not null”);
Thanks for pointing it out. It is really a problem. I will pay more attention about performance.
There are many dynamic_cast in engine. We can add more member variable or member function into Node to avoid it. But it will make Node fatter. As you can see now, Node is very complex now. We should keep a balance of complex and performance. If a function is invoked every frame, such as visit, we should make it as faster as possible no matter it will bring complex.
About Sprite::setDirtyRecursively, it will set _recursiveDirty and _dirty. These member variables are Sprite specific. I don’t think they should be moved to Node. If we did it like this, we may move more member variables into Node.
dynamic_cast costs really A LOT. Check this article http://www.nerdblog.com/2006/12/how-slow-is-dynamiccast.html It was written 8 years ago, but I don’t think that nowaday compilers can handle dynamic_cast much faster than then.
Moreover, in the usual game probably around 90% of the Nodes are the Sprites, so moving some stuff from Sprite class to Node class seems reasonable.
Agreed. I tend to be quite particular about performance. So I suggest for a start that anything that is called every frame or regularly should do passing by reference instead of a copy as passing by reference only passes a pointer to the reference and does not need allocation of memory space for copy
We’re doing the installer on both mac and windows these days. And in the last week, we tried to support compilation from static libraries instead from source code, to reduce the complexity for new users. @Martell your suggestion is quite good, I should consider the binary + header structure in the next week. For example, we can have a auto-compile-and-copy script to create such a structure from current cocos2d-x repo.