Label - Crash in the wild - iOS - Cocos2d-x v4

cocos2d::CustomCommand::updateIndexBuffer(void**, unsigned long) (in midnight) + 8*
cocos2d::Label::updateBuffer(cocos2d::TextureAtlas* *, cocos2d::CustomCommand&) (in midnight) + 160
cocos2d::Label::updateEffectUniforms(cocos2d::Label::BatchCommand&, cocos2d::TextureAtlas**, cocos2d::Renderer* *, cocos2d::Mat4 const&) (in midnight) + 72
cocos2d::Label::draw(cocos2d::Renderer**, cocos2d::Mat4 const&, unsigned int) (in midnight) + 1260*
cocos2d::Label::visit(cocos2d::Renderer* *, cocos2d::Mat4 const&, unsigned int) (in midnight) + 616
cocos2d::Node::visit(cocos2d::Renderer**, cocos2d::Mat4 const&, unsigned int) (in midnight) + 416*
cocos2d::Scene::render(cocos2d::Renderer* *, cocos2d::Mat4 const&, cocos2d::Mat4 const**) (in midnight) + 400*
cocos2d::Director::drawScene() (in midnight) + 396*
cocos2d::Director::mainLoop() (in midnight) + 148*

Looking at the code - my guess that textureAtlas is not null otherwise it would have tripped earlier - therefore I suspect there is an issue with the index buffer of the custom command.

void Label::updateBuffer(TextureAtlas* textureAtlas, CustomCommand& customCommand)
{
    if (textureAtlas->getTotalQuads() > customCommand.getVertexCapacity())
    {
        customCommand.createVertexBuffer((unsigned int)sizeof(V3F_C4B_T2F_Quad), (unsigned int)textureAtlas->getTotalQuads(), CustomCommand::BufferUsage::DYNAMIC);
        customCommand.createIndexBuffer(CustomCommand::IndexFormat::U_SHORT, (unsigned int)textureAtlas->getTotalQuads() * 6, CustomCommand::BufferUsage::DYNAMIC);
    }
    customCommand.updateVertexBuffer(textureAtlas->getQuads(), (unsigned int)(textureAtlas->getTotalQuads() * sizeof(V3F_C4B_T2F_Quad)));
    customCommand.updateIndexBuffer(textureAtlas->getIndices(), (unsigned int)(textureAtlas->getTotalQuads() * 6 * sizeof(unsigned short)));
    customCommand.setIndexDrawInfo(0, (unsigned int)(textureAtlas->getTotalQuads() * 6));
}

Have you created an issue on GitHub for this yet?

Hadn’t thought that far ahead - have now. [METAL] [iOS] Random crash when setting up MetalBuffers · Issue #20709 · cocos2d/cocos2d-x · GitHub

1 Like

With the number of iOS metal crashes I am seeing in the wild, and the fact that neither this forum or the GitHub issues gets any real attention… it seems that Cocos2dx c++ is indeed dead… looks like I backed the wrong SDK again and will need to look elsewhere… :frowning:

Cocos2d-x isn’t dead yet, but Creator and integration amongst our products has taken priority.

You can checkout ADXE for an active fork. Not sure if it requires many code changes for an existing project, but if you’re still in the initial/prototype phase and like the cocos2d style of APIs, how the scene graph and nodes work, that it’s relatively low-level, etc, etc, etc.

I won’t bother moving off Cococs2d v3.17 until OpenGL is no longer supported since I only maintain a few games at this point and nothing is in active development, but when I need to I’ll move it to this new fork or will just write and integrate v3.17 with something like BGFX or one of the OpenGL->Vulkan->Metal shim libraries.

For your and my intents and purposes the c++ engine has been dead for a few years now, with limited bug fixes. However, that doesn’t mean it’s not useful if you’re willing to fix any issues yourself or find open PRs or others in the community who have fixed an issue, or writings on how they ported to M1, etc.

So Cocos2d 3.17 or 4.x engines are usable as a foundation for your own “custom” engine for your future games, if you want, otherwise consider a fork like adxe or another platform altogether like Godot/Unity/Unreal/etc.

1 Like