Metal support RC0 released

I used the cocos command, it didn’t generate the .xcodeproj file either.

cocos new MyGame -p com.MyCompany.MyGame -l cpp -d ~/MyCompany

this is what I did

cocos new doesn’t generate .xcodeproj file, you should use cmake to generate it.

thank you for the answer. I’ve made it work with cmake

I managed to get the hello-world app compiled and to run on a device with metal support. However, when I run the same on an older device without metal, i get an error saying that the device does not support metal and the app crashes. Shouldn’t OpenGL step in when metal is not available? Are devices without metal dropped in v4?

Hi. Apple deprecate OpenGL ES and maybe not supporting it in the next year. Then all devices without metal support dropped by Apple. I think we don’t need OpenGL ES for Apple devices after Version 3.x.

I understand that Apple side of the story. My question was for the Cocos2d-x side of the story. The documentation here says

… Cocos2d-x v4 adopts Metal for it’s rendering engine on Apple platforms. If metal, is unavailable on your platform, OpenGL will then be used to render.

Like to know if the condition “If metal, is unavailable on your platform” also includes older iOS/macOS platforms. No problem either way. Just like some clarity as we need to make some decisions for a new app. Thank you.

@nedumaran for iOS/macOS platforms, V4 only works on those devices that support Metal. The document of If metal, is unavailable on your platform, OpenGL will then be used to render. is an incorrect representation and will be removed later.

@coulsonwang Thank you so much for the clarification.

What about mac os? There is still many older mac os devices, unable to run osx 10.14+ with metal. Should we have fallback opnegl mode for such devices?

@hexerror As Metal wiki said, On macOS, Metal supports Intel HD and Iris Graphics from the HD 4000 series or newer, AMD GCN-based GPUs, and Nvidia Kepler-based GPUs or newer.
For older mac os devices, you can use v3 version instead.

Hi. I’m testing cocos v4 on macOS and iOS, and it looks like shaders are not working when they are applied to SpriteBatchNodes. They only work on Sprites that are not part of a batchNode.
Is there anything else I should do apart from assigning the shader (backend::ProgramState) to the SpriteBatchNode with setProgramState?

@kmaker it is better that you provide a demo to describe it.

@zhangxm please take a look to the code below. Shader is not being applied when set on the batch node:

std::string fileImage = "sample.png";
SpriteBatchNode* batch = SpriteBatchNode::create(fileImage);
batch->setProgramState(new (std::nothrow) backend::ProgramState(program));

Rect rect;
rect.size = batch->getTexture()->getContentSize();
Sprite* bg = Sprite::createWithTexture(batch->getTexture(), rect);

but if it is applied directly to the Sprite, it works:

Sprite* bg1 = Sprite::create(fileImage);
bg1->setProgramState(new (std::nothrow) backend::ProgramState(program));

Am I missing something?

@kmaker What’s your program type?

I tried a few. Here’s one:

auto* program = backend::Program::getBuiltinProgram(backend::ProgramType::GRAY_SCALE);

@kmaker fixed in PR 20344.

Perfect! It’s working now. Thanks

Hi. Why is instance variable backend::ProgramState* _programState duplicated on so many classes? It is already defined on superclass Node.
This leads to unwanted behaviour. For example, if you set a ProgramState on a Label and then retrieve it using getProgramState, you will get a different one! That’s because getProgramState is defined by Node, and so the the ivar returned is the one from Node rather than Label.

@kmaker yep, it’s duplicated. We forgot to remove the _programState in derived classes. Fixed in PR 20350

Great! Thanks for fixing it so quickly.