Are you using v4 Metal currently?

Are you using v4 Metal currently?

Ok! Btw why was SimpleAudioEngine removed?

API changes docs look detail enough. Good job.

  1. I believe there is a mistake in remove getFontDefinition and setFontDefinition.


  1. Regarding removal of cocos2d::LabelBMFont and cocos2d::LabelTTF, what are we going to use instead is not specified? Is their functionality incorporated in Label?

@kerryk thanks for the feedback.

  1. Yep, i think it is a mistake. @PatriceJiang please check it.
  2. You can use Label, there are Label::createWithTTF(), Label::createWithBMFont() and so on.

I have a very large cocos2d-x 3.15.1 project. I have managed to create a cocos2d-x-4.0 beta xcode project using cmake. However, now i want to copy all v4 cocos file to my existing xcode project and not the other way around. Is there a nice tutorial somewhere?

I think you can do it in opposite way. You can copy all you game codes into new v4 project. Just modify the CMakeLists.txt to include the game files.

Its not that simple. I have other projects dependencies too. I work as workspace for cocoapods, many other internal company libraries, setup build phases, many existing build settings etc. It makes more sense to transfer v4 to existing. Especially if company needs to do these for all its projects, it makes more sense to copy cocos. But ok, out of topic here since tehre is another post New project creating with cocos v4 (cmake for everything) .

@kerryk just so you realize the history, this method has been how it has worked for so many years. I’m not saying there shouldn’t be other methods of upgrading projects but just so you have the history of why we think this way.

I used to do it the way you suggest. I would take my existing 3.x project and when 3.y came out I would overwrite the cocos2d folder and open AppDelegate, RootViewController, etc and do a diff to see what had changed, then looked an build settings and compared, etc, etc. This would usually work after some trial and error because I could overlook a small detail (like a compiler flag) and spend so long tracking down small details. Once I started doing cocos new and copying in my source and resources, things got better. However, I did have to keep detailed notes of anything special I was doing to make sure I re-did those steps in the new project.

If you have a large project and dependencies this may be tougher for you. Perhaps if you describe the setup folks here can chime in and help with ideas. Many heads, make light work…well you get it. :slight_smile:

@slackmoehrle i have provided here.

Im trying to run project made using cmake on xcode 11 simulator. Since simulators now support metal, game should run. I am getting a lot of different kind of errors such as:

  1. unsupported architecture (i guess can be solved by including simulator in build settings)
  2. Unknown type name ‘__int64_t’; did you mean ‘__int128_t’?


ps.s Version 3.15 can run on xcode 11 if bullet physics library is removed.

As i know, simulator supports metal need macos 15? And it is not released.

you probably might be correct, i will try to figure that out

TL;DR I like the Metal and cmake workflow of v4 very much!

I have started using it and it’s working very well. I have been out of the loop for a while now, so I wonder if you wouldn’t mind clarifying something for me…

Is cmake going to be the only supported way to bootstrap your projects with v4?

If so, then good! I feel cmake produces much cleaner projects as with the provided v3 projects I often found stale include/lib references. The only penalty is the need to re-run cmake whenever source code or resources are added/removed, but both Xcode and Visual Studio picking up these changes without the need to restart, it’s no big deal.

What also wasn’t clear was how you now start your own project when using the source code version of cocos2d-x. I managed to create a project using cocos2d-x as a git submodule and copying the cpp-template and modifying the CMakeLists.txt files to create a working project without too many problems and have tested this with macOS, iOS and Win32 so it’s certainly a workable solution.

Other things…

I am running macOS 10.15 Catalina beta 5 with both Xcode 10 and Xcode 11 beta and can only get an iOS build using Xcode 10. I know how to fix this and plan on doing that shortly, if you are interested in a PR?

Other than that I would say Metal is working out very nicely (well done @zhangxm) but when doing a GPU Frame Grab I noticed that the viewport is being set for every draw call, which I doubt is really necessary?

Yep, it makes add/remove resources and change compiling flags very convenient. You don’t have to modify Xcode project file in MacOS, VS project file on windows, and on Android and so on.

Please create a new topic for it.

And thanks for trying v4.

OK all good. I will look at the code and make a PR and topic when I look into it, which may not be until Sunday.

I would like to give it a trial, which remote branch should I checkout? metal-support, v4, or v4-develop?

@stephenhurry the only v4 branch in our repo is: and it was updated just 2 hours ago. I’d say use this one. I believe the team is starting to prepare for releasing and making adjustments to locations, etc.

1 Like

Yep, it is v4 branch.

  1. Could you provide release date?
  2. Do you have any performance tests to compare v4 vs v3 renderer?
  3. Do you have roadmap for v4?
  4. Will you close branch v3 and continue development in v4 only?
1 Like

the iOS Xcode project cannot be created and I get this error: Could not find toolchain file: ../cmake/ios.toolchain.cmake

It is because it is not needed. And the usage changed: We will update the docs soon.