Cocos2d-x 3.0 Online Party

[shuin4646]

What I mean is this http://raymondlu1983.blog.com/super-animation-converter/ , I find it easy and much reliable than dragonbones for cocos2d-x.

[fusijie]

Refactor the animated sprite code to use less lines of code. Now it is

Vector<SpriteFrame*> animFrames(15);
char str[100] = {0};
for(int i = 1; i < 15; i++)
{
sprintf(str, “grossini_dance_%02d.png”,i);
auto frame = SpriteFrame::create(str,Rect(0,0,40,40)); //we assume that the sprites’ dimentions are 40*40 rectangles.
animFrames.pushBack(frame);
}

just to create a vector of sprite frames. So better to refactor it and put it in an official cocos2d-x function?

I don’t think it’s a good idea, you should pass lots of arguments to the function, eg. picture name, count, begin pos, end pos, rect and so on…

[zijian_rao]

What I mean is this http://raymondlu1983.blog.com/super-animation-converter/ , I find it easy and much reliable than dragonbones for coos2d-x

Good! It looks convenient, I’ll try it.
And we would recommend this to developers if it was really good~~

[Hoangtaiki]

Suggest:

• An Editor where have “Scene Vỉew” and “Game View” like Unity3D?

[shuin4646]

What I’m doing is like this, and I also agree for better and simpler function call.

CCSprite* Utils::createAnimation(const char* pPlist,const char* pCommonName,uint32_t pStartFrame,uint32_t pEndFrame,float pFrameDelay,bool isLoop)
{
CCSpriteFrameCache* cacher = CCSpriteFrameCache::sharedSpriteFrameCache();
cacher->addSpriteFramesWithFile(pPlist);

const int kNumberOfFrames = pEndFrame + 1;
CCArray* frames = new CCArray;
frames->initWithCapacity(kNumberOfFrames);
for( int i = pStartFrame; i < kNumberOfFrames; i++ )
{
    CCString* filename = CCString::createWithFormat("%s%d.png",pCommonName, i);
    frames->addObject(cacher->spriteFrameByName(filename->getCString()));
}

CCSprite* sprite = new CCSprite;
CCString* dummy = CCString::createWithFormat("%s1.png",pCommonName);
sprite->initWithSpriteFrameName(dummy->getCString());

CCAnimation* anim = new CCAnimation;
anim->initWithSpriteFrames(frames, pFrameDelay);

if(isLoop)
    sprite->runAction(CCRepeatForever::create(CCAnimate::create(anim)));
else
    sprite->runAction(CCAnimate::create(anim));

//cacher->release();
return sprite;

}

[Hoangtaiki]

I am interested in it I will try it

[zijian_rao]

Suggest:- An Editor where have “Scene Vỉew” and “Game View” like Unity3D?

CocoStudio Scene Editor can view the game scene, even view it on your smart phone through QR code.

[Hoangtaiki]

Thank you. I will try CocosStudio for Mac. Hope that release version will come soon.

[nbtthief]

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

[chen]

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

We totally get that and will improve it in the future versions!

[chen]

Can you put in scene transitions when you pop a scene from the stack now?

My colleague is giving that a try. Will answer you later (probably not before this party ends though).

[chen]

OK the party is ending! Thank you all for your participation and precious ideas! BTW wait for our prizes:)

[SonarSystems]

!!!

[Martell]

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.

Awh I was too late for the party

[pabitrapadhy]

Yes . I do agree .

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.

[dotsquid]

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)

Mat4 nodeToParent = getNodeToParentTransform();
Mat4 parentTransform = static_cast<Sprite*>(_parent)->_transformToBatch;

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.

[chen]

gibtang said:
Can you put in scene transitions when you pop a scene from the stack now?

Try modify the engine with: void Director::popScene(const std::function<void(Scene* &)>& callback)
{
CCASSERT(_runningScene != nullptr, “running scene should not null”);

_scenesStack.popBack();
ssize_t c = _scenesStack.size();

if (c == 0)
{
    end();
}
else
{
    _sendCleanupToScene = true;
    _nextScene = _scenesStack.at(c - 1);
    callback(_nextScene);
}

}

And use it like: auto callback = [](Scene*& scene){scene = TransitionJumpZoom::create(1.0f, scene);};
Director::getInstance()->popScene(callback);

Just for reference; it can possibly cause other bugs so be careful…

[zhangxm]

@dotsquid

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.

[dotsquid]

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.

[zhangxm]

@dotsquid

Thanks for sharing. I will do more test for it. And i will paste the result here.