cocos2d-x v3.0-beta2 available for download

Error: cocos2d: removeAction: Target not found

I got it constantly after instantiation and playing first animation in UI element, created in Cocostudio UI editor.

It is very simple UI with 3 images, one image has animated position and alpha.

withing
void ActionManager::removeAction(Action *action)
{
there are HASH_FIND_PTR(_targets, &target, element);

but _targets is nullptr.
Animation is displayed correctly, but error appear each 2 seconds.

I use this code to create Widget and play animation

widjet = cocostudio::GUIReader::getInstance()->widgetFromJsonFile(“fan.json”);
ret->retain();

current_animation = cocostudio::ActionManagerEx::getInstance()->getActionByName(“fan.json”, “idle”);
current_animation->play();

Please advice.

PS: I can’t understand, am I right to call animation through ActionManageEr. It seems I may have only ONE widget instance for each JSON file, because instance is binded within AnimationManager to it’s filename.

I’ve got some issues on win32. I created a new project, changed the helloworld demo so that it has 4 sprites, one player, and 3 background images. I have one update method, which will update the background and the player. There is nothing complicated in my code, nothing that should drop the fps, but still it does.

It starts at 60 fps, then randomly drops to around 30. Then, if I move the window containing the game, it goes to 60 fps and after that it drops again to 30. I created a release version, so the visual studio debugger doesn’t affect performance. See the video attached.

Does anyone know if this is a bug, or if I have to change some setting I don’t know of? (the fps is set to 60)

void EventDispatcher::dispatchEventToListeners(EventListenerVector* listeners, std::function<bool(EventListener*)> onEvent)
{
  skiped

    // priority < 0
    if (fixedPriorityListeners)
    {
        bool isEmpty = fixedPriorityListeners->empty();
        for (; !isEmpty && i < listeners->getGt0Index(); ++i)
        {
            auto l = fixedPriorityListeners->at(i);

at last row we have i == 1 and fixedPriorityListeners->size() == 1.
It means out of range exception.

It is bug of cocos2d-x.

I will try to find time and write reproduction steps.

Bitmap font Error:

void TextBMFont::setFntFile(const char *fileName)
{
    if (!fileName || strcmp(fileName, "") == 0)
    {
        return;
    }
    _fntFileName = fileName;
    _labelBMFontRenderer->initWithString("", fileName); 

last string raise exception: CCASSERT(!_configuration, “re-init is no longer supported”);

But if change it on:
_labelBMFontRenderer->setFntFile(fileName);

works like a charm.

PS: I feel maself abadnoned. Latest bugreports passed without notices. I feel the drama within.

Excuse me,I want to know when the effect of label will improve ? Because I need it in my project.:smiley: :smiley:

Hi ,@Delka
Sorry for my late reply. Thanks for your feedback.
I created two issues:
http://www.cocos2d-x.org/issues/4160 for EventDispatcher
http://www.cocos2d-x.org/issues/4161 for Label

We’ll fix it next week. :slight_smile:

Hey,@Delka ,
I could not reproduce the issue of EventDispatcher, could you please let me know how to reproduce it? Thanks.

@Delka,
The issue of out of range exception has been fixed at https://github.com/cocos2d/cocos2d-x/pull/5503 .
Please apply that patch, thanks.

@Delka LabelBMFont re-implemented as a wrapper of Label already.The issue not exist now.

I am sorry but I wrote the bugs from 3.02. I feel I mess something.

Should I update from your latest build at GiT-repo?

PS: as I understand the issue with EventDispatcher is fixed?
PPS: the issue uppear if add/remove fixed priority subscribers ( priority < 0 )
if we subscribe it once and never remove - it works, but if we remove it - bad things start to happen. I did simple research and looks like something with reference count, but it can be due to the lambda-functions in main loop.


What abut render? You (team) left many TODOs and it intrigus me.

Due to the fact I have to get into it deep enough:

Bug: I am sure GLProgram pass incorrect MV matrix into shaders, because at time it updates uniforms kzm lib do not hold the objects matrix.

Also, please, can you describe why do you render triangles while all stuff is quads? If you remove dat QUAD dependencies and make QuadCommand to work with raw triangles it will allow to pass any mesh into it. Even complex mesh, because one sprite can provide multiple commands to the renderer.

I am ok with triangles, but will it be more efficient to not to use indices? At any case you always copy pixels to a buffer. Well, what I see there I assume as idea in a half. You stop in the middle. As for me, too many memory copies and calculations of matrices and vert*MV on CPU.
So I have huge expectations as for future updates :wink:

Should I update from your latest build at GiT-repo?
PS: as I understand the issue with EventDispatcher is fixed?
PPS: the issue appear if add/remove fixed priority subscribers ( priority < 0 )
if we subscribe it once and never remove - it works, but if we remove it - bad things start to happen. I did simple research and looks like something with reference count, but it can be due to the lambda-functions in main loop.

Yes, the issue is regard to fixed priority subscribers. I fixed that issue. We probably release a 3.0 rc version this week. And getting your feedbacks, So we could have enough time to fix in before the 3.0final release next week( before 2014.3.15).
If you can’t wait, please refer to my changes in that PR. Thanks. :slight_smile:

@Delka Thank you for your feedback.

For bug in GLProgram: Our test cases work fine. Can you help me to give us a short test cast to demonstrate the bug? It would be very appreciated.

For supporting triangles mesh: We will discussing about this feature. We will notify you our progress, please give us some user cases and feedbacks.

For efficiency:

A. indicies efficiency, Indices is very efficient in 3d situation. A 3d mesh with 2000 triangles may only have less than 1000 vertices. It is drawn by one glDrawXXX Call, if we use indices, we need to process 1000 vertices, and 2000*3 vertices without indices. In our situation, I guess it may be not that efficient as 3D, we mostly draw 2 triangles only in one glDrawXXX call. However, we can give a performance test for this.

B. CPU bound on vertice processing, as you suggested, we may have CPU bound due we processing much on vertices, memory copy, matrix calculation, vert*MV.
We did this for we need to pack draw data into one vertex buffer. It is a trend if we have numerous vertices. We have tested performance for this (testcpp->PerformanceTest->spritePerformanceTest), that we have tested 3000 sprites on E9, E10(sprite is small, no bottleneck on GPU), which can get 60 fps on iphone 4s. It is not our performance bottleneck. For we have not found better solutions, we decide to use this. Do you have any other solutions? Thank you.

@dumganhar wrote:

Yes, the issue is regard to fixed priority subscribers. I fixed that issue. We probably release a 3.0 rc version this week. And getting your feedbacks, So we could have enough time to fix in before the 3.0final release next week( before 2014.3.15).
If you can’t wait, please refer to my changes in that PR. Thanks. :slight_smile:

Thanks, I will wait :slight_smile: Will try to send reports of bugs if found asap :slight_smile: I am sure there is a bug in animation of cocosstudio AnimationEditor. If I assign animation (at least one key) not for all layers, I have errors when play animation in the game.

Idea, cocos-x is very strict as for inner classes when loads armature/widgets. It will be nice to register factory or classes withing loader to push my objects into it.

@dabingnn wrote:

@Delka Thank you for your feedback.

Thank you! I see I have got a lot of attention :slight_smile:

Well. I know it is not your bottleneck. :slight_smile: At debug time our perfomance was affected mostly by ‘visit’ function :slight_smile: at release compilation I have stable 60 fps (Ipad2) and have no idea where dat bottle neck is. But I assume it will be, when our scene will be large enough because I see that culling (reject of adding of render order) is commented in draw function.

As for ideas, well, I understand cocos-x is generic engine for all cases. As for our game, it has MANY static sprites that are changed never. All of them are childs of one sprite. And when it goes about optimization all my brain powers are spend for optimization of our specific case.
What really I can suggest is:

I see your Z ordering logic is based on fixed order of sprites defined by dependency tree an local/glovbal Z order. But withing games such level of eh strict ordering is not needed. What I as gamedeveloper take care about in my games is:

Object is fully/partialy covered by other object:
A by B
B by Z

C by K + Z
K by Z

At that case I can render A and C at any order, also after A+C I can render B and K at any order. after that goes Z. This freedom opens new options for efficient sorting by material to reduce change of materials. At your case I have to think about what atlas have to hold each of texture assuming the order of possible rendering.

Yes, I can make your ordering work takin in account real demands for ordering, but I have to play with Zorder property too much, and that algorythm have to know not the texture, but the atlas of the sprite. That is not so easy.

Also what I am thinking about regarding such games is 2 large enough static pairs of buffers that hold real vertices (Sprite request vertices from that buffers) and somekind of defragmenter in other process. With previous technique and packing all textures to large atlases (also to decrease reconfiguring of render pipeline) may have interesting results. But this is dream :slight_smile:
As a sample of such kind of strange kung-fu there was a developers diary many-many years ago from developers of Age of Empire, they have huge issue with memory fragmentation due to large quantity of created/died units. So they redefined operator ‘new’ and used DirectX memory allocation routines (used by DirectX for textures). That functions have heavy algorithm to prevent fragmentation, it helped a lot :slight_smile:


As for triangles and user cases. Well, you provide the user case yourself :slight_smile: I have to render 3D object. I have to make custom render command, because I have to provide quads to QuadCommand, but I have triangles… so I have made custom command and use: static vertex buffer, shader with MVP and…

You take care about Gpu, default shaders have no any matrices multiply :slight_smile: but put a lot of work to Cpu that can be used to make some other usefull staff. Also I see you use dynamic buffers - as for iPhone etc it is good, because mem is shared (am I right?). But as for PC, I assume it will require to send buffer to a video card.


As for bug in GLprogram:
Renderer calls cmd->useMaterial() it calls the _shader->setUniformsForBuiltins();
it calls kmGLGetMatrix(KM_GL_MODELVIEW, &matrixMV);
it gets kmMat4Assign(pOut, modelview_matrix_stack.top);
modelview_matrix_stack.top <==

But when render get’s into the main Rendering loop you processed matrices at:
if (_runningScene)
{
_runningScene->visit();

so what you get from the top of matrices stack is (actually what is is? MV of root?) but whatever it is - it is the same for All rendering time. It simply can’t be the valid MV for each set of vertices.

At Renderer :
memcpy(_quads + _numQuads, cmd->getQuads(), sizeof(V3F_C4B_T2F_Quad) * cmd->getQuadCount());
convertToWorldCoordinates(_quads + _numQuads, cmd->getQuadCount(), cmd->getModelView());

you use cmd->getModelView() that is correct MV of cmd (its Sprite), but when you call material you use top of matrices stack…

To get in working in my case I commented material->use() and wrote
_shaderProgram->use();
_shaderProgram->setUniformsForBuiltins(_modelViewTransform); << ---- I pass real MV matrix. It works like a charm. I have nice and tasty 3D model with static buffers and all computations on Gpu :slight_smile:

May be I messed somewhere, may be your Unit Test is not complex enought to reproduce the case. Who knows? But I want peace for all Cheers! :slight_smile:

Oh, I am so complex :slight_smile:

Gratz with RC!
Nice job.

I have a few issues with RC0 and which also persist in latest download from GitHUB (if I download code as a complete zip).

I use LabelTTF a lot right now like:

_coinLabel = cocos2d::LabelTTF::create(_coinString.c_str(), "Marker Felt",32);
_coinLabel->setColor(some custom 3B color);

With Beta 2 everything was fine. Now with RC0 my labels are showing up different shades of colors and they dont look quite the same. The font is duller and looks smaller, some show up the correct color I specify others dont.

Also, along the same lines, now some of my sprite png’s are showing up weird shades. Example, one should be brown and it is loading a bit red looking. One is green and loading a much darker green.

Here is an example of what I do to create:

    // bux label and sprite
    _buxLabel = cocos2d::LabelTTF::create(_buxString.c_str(), "Marker Felt",
                                           (32 * APPDIRECTORINSTANCE->getScaleFactor()));

    _buxLabel->setHorizontalAlignment(cocos2d::TextHAlignment::LEFT);
    _buxLabel->setVerticalAlignment(cocos2d::TextVAlignment::CENTER);
    _buxLabel->setColor(SMColors::cGold3B);

    _coinLabel->addChild(_buxLabel, 0);

    _buxLabel->setPosition(cocos2d::Point(_coinLabel->getPosition().x,
                                           _coinLabel->getPosition().y -
                                          80 * APPDIRECTORINSTANCE->getScaleFactor()));
 
    _buxSprite = cocos2d::Sprite::createWithSpriteFrameName("bux.png");
    _buxLabel->addChild(_buxSprite, 0);
    _buxSprite->setPosition(cocos2d::Point(_buxLabel->getContentSize().width +
                                           30 * APPDIRECTORINSTANCE->getScaleFactor(),
                                           _buxLabel->getContentSize().height / 2));

is there a way to make a transparent background scene?

I tried but I always get opaque black background. I opened a thread here

@Delka We are busy preparing for our 3.0rc0 release. Sorry for my late reply.

  • Our culling has been re-added again, using a faster cull algorithm. For large scale scene, it could be more helpful.

  • We have not pay much attention on the draw order and the occlusion optimisation. To reduce material change, our auto-batching is helpful, however, I think in some special scenario, using textureAtlas could reduce material change more.

  • Your consideration is right, we will test the performance of move matrix calculation into shader and see the comparison.

  • For your bug, could you please give us a test case?

cocos2d-x3.0rc0 + android i9000:

03-30 00:37:47.164: E/NativeActivity(7435): channel ‘409b3b80 ****.Cocos2dxActivity (client)’ ~ Failed to receive dispatch signal. status=-11

how to fix it ?
thank you