Cocos2d-x V4.0 released

Cocos2d-x V4.0 released

I see this a little another:

RenderTexture::onBegin() call’s renderer->setRenderTarget(_renderTargetFlags, _texture2D, _depthStencilTexture, _depthStencilTexture); which exchange render->_renderPassDescriptor corresponding values.
(This allows to have one Frame buffer (with id == 1) and many others attachments combinations.)

RenderTexture_1::onBegin() -> set new depth/color/stencil values for _renderPassDescriptor

RenderTexture_1::onEnd() -> set old depth/color/stencil values for render->_renderPassDescriptor

RenderTexture_2::onBegin() -> set new depth/color/stencil values for _renderPassDescriptor

RenderTexture_2::onEnd() -> set old depth/color/stencil values for render->_renderPassDescriptor

Suppose, that there is only depthAttachmentTexture for RenderTexture_1.
Each calling of Renderer::drawXXXXCommand() will call CommandBufferGL::applyRenderPassDescriptor(). This function disable colorAttachmentTexture via

But there is no enabling it for RenderTexture_2. I mentioned how to patch this behavior in previous message.

About demo:
Common cocos2d::RenderTexture::onBegin() and onEnd() form CallbackCommand and put it to the render queue where z == 0 (There is five render queues in render engine).
This helps for cocos2d::Sprite, but not for cocos2d::Sprite3D, since MeshCommand will be put to the Opaque or Transparent render queues.

My custom RenderTextureCustom does the following:
RenderTextureCustom::onBegin() -> put CallBackCommand to Opaque queue RenderTextureCustom::clear() -> put CallBackCommand to clear depth/color/stencil to Opaque queue

RenderTextureCustom::onExit() -> put CallBackCommand to Transparent queue.

That is exactly what my class performs. Sorry I do not have any demo, but I can provide you this class if you want.

I know that cocos2d::RenderTexture does not allow to be created without colorAttachmentTexture on the one side. But as I can see low level api should be possible to handle similar cases (different attachment combinations).

Sure, I recommend:

  1. Updating this post to clarify ‘removing OpenGL support on iOS’ or ‘replace OpenGL with Metal on iOS’
  2. Updating cocos2dx v4 github readme to not say iOS8+ but to say iOS8+ & Metal supported device (with some sort of info or link to device support)

To avoid this confusion in the future.

1 Like

@solan I think it needs to specify the GL_COLOR_ATTACHEMNT0 to enable reading from/drawing to color buffer again.
Could you help to post your fix to the v4 branch?

@coulsonwang I wish I could help but I have no githab account to do pull request, I use bitbucket.
(If there some opportunities to do pull request from bitbucket account?) Or can I do it via git request-pull ?)

To save time, you can try this file.

CommandBufferGL.cpp (19.8 KB)

Copy it please to the renderer/backend/opengl/CommandBufferGL.cpp

It differs from origin only in fixing of this issue. I believe that it helps.
Of cause it will require some changes if you will decide to support multiple color attachments.

But I beg you to let me know if you think that this fix is not appropriate for some reason.

So, i download and installed v4, followed by CMake guide at cocos docs. But one thing is still unclear for me: how to create new project, f.e. for ios, with specified app name, bundle identifier and so on? Because, by default, “cmake … -GXcode” command create a bunch of pedefined projects, including cpp-tests, HelloWorld etc. Should i add new target at xcode project, fill all needed info by hands, or should i rename one of exist targets, HelloWorld f.e., alter it to satisfy my needs? And what about android projects? I need some guidance.

I just ran this:

cocos new v4Test-1 -p -l cpp -d /Users/jason/icloud/Cocos/Cocos2d-x/.

and now you can use CMake to generate the Xcode project per the docs

Unfortunately, “cocos new” command does not work anymore in v4:
“-bash: cocos: command not found”

it works for me. What is your path? is cocos there? git you run ./download-deps and git submodule init if you cloned from GitHub.

I talked to engineering and cocos new ... is the correct way.

1 Like

Yes, it is my mistake. I was able to create new project via “cocos new”… without any .xcodeproj files inside. What to do next, to generate those files for ios & osx?

Congratulations to everyone. Great Job.

This is where you use CMake like in the docs Minggo posted.

I might make a quick video about this for people.

1 Like

Congratulations, this is a fine achievment indeed, as it always has been, and always will be.

Transfer my project to v4, heavily testing now - so far so good :slight_smile:

1 Like

Thanks for the Metal support!

I have noticed the js-bindings no longer exists. Any plans to keep support that?

I can also see that CCScrollView is commented. Is it going to be supported too?

1 Like

@alonlevylll v4 will not support js-bindings. About CCScrollView, did you mean extensions/GUI/CCScrollView? If so, i think you’d better change to use ui::ScrollView. CCScrollView is created to support Cocos Builder, and CocosBuilder is not supported for a long time. We keep CCScrollView just because cpp-tests depends on it, and forgot to remove it.

1 Like

I have some troubles with V4 ios xcode project: When time has come to distribute my app to TestFlight, it turns out that i can not Archive project to validate&distribute to app store. In best case (if i change build system from Legacy Build System to New Build System), i get broken archive under “Other Items” instead of “my app name”, which is, if opened in finder has empty Products folder; in worse case, if don’t manage with build system at all, leaving it to default Legacy Build System (orange warning hammer sign in xcode notification area), i get nothing at all not even a broken archive. So i stuck at release app state and don’t know what to do next…

Found a way to fix this issue: on “Target app -> Build Settings -> Deployment -> Installation Directory” put: $(LOCAL_APPS_DIR)
(this field is empty by default in new cmake-created project, can somebody create PR?)

Sorry, i don’t quite understand the issue. I just make an archive app, it works. The app is in /Users/minggo/sourcecode/cocos2d-x/tests/cpp-empty-test/ios-build/bin/cpp-empty-test/Release/

If you create new project via “cocos new”, then create xcodeproj via cmake, then sign project and try to archive it - it will be broken, as i’m mention before - generated project missing Installation Directory.

I tested right now, it works. The steps are:

cocos new -l cpp
cd MyCppGame/
mkdir ios-build
cd ios-build
cmake .. -GXcode -DCMAKE_SYSTEM_NAME=iOS

Then archived it. cocos run will create a Xcode project, but this Xcode project only works for simulator. It is a bug, we will fix it. So how did you create Xcode project?