Metal support beta0 released

Metal support beta0 released

Compare to alpha1, this version finishes these work:

  • full support support lua binding
  • linux adaption
  • fix EGL context lost on Android
  • remove JSB/h5
  • remove SimpleAudioEngine
  • many bugs fixed


v4.0 beta0

How to run

  • mac: use cocos command or CMake
  • iOS: use CMake to generate Xcode project, then run
  • Android: use cocos command or Android Studio
  • windows: use cocos command or CMake
  • linux: use cocos command or CMake

CMake usage can refer to cmake/

Next plan

  • add docs for v4
  • add API comments
  • release rc0

You are appreciated to test and give feedbacks.


Sorry for asking this again.
I take it as JSB is going to be removed forever going forward?

Yep, if you want to use JS, i think creator is better.

We have many projects that used JSB.

Please don’t remove it.

You can use v3 instead.

@zhangxm Is there any documentation available for the process of upgrading from V3 to V4? The area I’m specifically interested in is related to shaders, since the API has changed significantly, and there seems to be less pre-defined shaders available.

For instance, v3 has ccPositionTextureColor_noMVP_vert defined, but v4 does not, so there is no obvious replacement that I can see. I’ll be digging into the shader code to see if there is something similar.

Also, in v3 you have things like this:

GLProgram::createWithByteArrays(vertSource, fragSource)

Yet in v4, there is no equivalent, so from looking at the cocos code, I assume we would need to do this:

backend::ProgramCache::getInstance()->newProgram(vertSource, fragSource)

I haven’t had time to dig into the code to see what the new system is like, and even then I may not understand it completely.

So, if there is documentation detailing what is required to upgrade from v3 to v4, relating to what changes are required etc., then it would be of great help with adapting the current game code to use v4.

So far things seem to be working ok, except for a strange issue with global Z sorting with v4 that does not happen with v3. I’m looking into at the moment to determine if it’s a bug in my game code or in the v4 engine code.

Also, there are fixes in the v3 github branch that have not been ported over to the v4 branch. Will these be merged in at some point?

EDIT: There is some strange behavior with clipping areas. If there are multiple clipping areas adjacent to each other, and they are all children of the same parent node, then the first clipping area added to the parent will cause all other adjust clipping areas to clipped out incorrectly. I’ll do my best to get a simple project to reproduce this.

EDIT: cpp-tests, 25:Node: Clipping -> Test #2 is not working correctly (Win32 debug build, VS2019). The holes should be an image, yet they’re just empty squares. I’m not sure if it’s related to the issue I’m experiencing though.

But we need update our iOS project.

So we need Metal support?

@yehsam1 i think you can still use opengl on iOS.
@R101 sure, we are writing it. And i will create a new thread for it. Then developers can ask requirements or help to write the docs.

There is definitely something wrong with the v4 clipping.

I’ve attached the source files and resources of the test I did, which you can use in both v3 and v4 of cocos2d-x to see the difference.

Expected: Using Cocos2d-x v3.17.2 with 3 clipping nodes each shown by the border color:

Actual: Using metal beta0. Only the top clipping node is visible, the others below it are not visible, and possibly being clipped by the top node when they shouldn’t be:

Source code: (638.0 KB)

Isn’t OpenGL is going to be depreciated in next iOS?
That is the main reason of this Metal project.

Yep, it is deprecated, but not be removed. We don’t know when it will be removed.

1 Like

We must update our project’s Engine before OpenGL has be removed.

Why not keep JSB files?

@R101 There is some wrong with stencil write mask setting in V4, and it was fixed in this PR

@coulsonwang Thanks for the update. I’ll merge the fix into my local code and test it out.

EDIT: I just tested it, and it has fixed the clipping issue in my game. :slight_smile:

hello @zhangxm
what steps do I take to get spine working in metal beta.
I’ve tried including spine from the pull request
Doesn’t seem to be working for me.

@bilalmirza I’m attaching the Cocos2d-x Spine C++ runtime that I’m using at the moment, and I’ve made it work for both V3 and V4 of Cocos2d-x (due to some magic in the /spine-cocos2dx/CMakeLists.txt).

Check the readme.txt file that’s in the zip file for how to integrate it with your game. Extract the contents so that they are at the same level as your Classes folder.

So it’ll be like this:
[your game path]/Classes/
[your game path]/external/spine etc. (341.1 KB)

I hope that helps.


@bilalmirza i think we can just keep the PR, and will not merge it into cocos2d-x because of the license. As using cmake, it will be easy to integrate it. And we will write a docs about it. About the working issue, i asked @PatriceJiang to take a look.

@R101 great work.

// add this after the line “target_link_libraries(${APP_NAME} cocos2d)”
this line doesn’t exist in metal support beta

I don’t understand what you mean? I checked the /templates/cpp-template-default/CMakeLists.txt, and I can clearly see that it does exist, at line 126:

target_link_libraries(${APP_NAME} cocos2d)
        PRIVATE Classes
        PRIVATE ${COCOS2DX_ROOT_PATH}/cocos/audio/include/

This is the template that is used to generate the game project folder using the cocos new ... command.

As I stated in my previous post, the files I attached need to be extracted into your game folder, where the CMakeLists.txt exists, the one you need to edit.