After one year’s hard work, we are happy to announce that cocos2d-x v4.0 is released. If you want metal support on iOS/macOS, then you should use this version. If not, then you can still use v3.x.
Spine runtime is not included in the zip file as the codes is not merged in Spine runtime official repo. But you can check out the PR to use spine runtime. Or you can get the patch file and do patch by yourself. The patch file is generated by git diff commands.
Besides Metal support, is this a relatively minor update from cocos2d-x 3.x? Feature list seems to mostly be updating libraries and removing outdated libraries and code. No significant changes to functionality?
Wait what!? Support Metal = No longer support OpenGL???
This wording is completely wrong. It isn’t ‘support meta’ but ‘replace opengl rendering with metal’
This fundamentally changes the supported device spectrum for cocos2dx.
The github still states ‘iOS 8+’ which is no longer the case.
Was this confirmed anywhere until this sudden release? Even I had the understanding that opengl remained as a side-by-side renderer option???
(Just to add: we clearly understood that custom GL commands would no longer work in platform-agnostic code, but presumed this was to handle both renderers, not that GL was being fully removed.
For reference, we would lose X% users by dropping support for OpenGL-only devices meaning the metal upgrade no longer holds enough value until Apple forces a move away from OpenGL)
getImageData(…) set ePixelFmt to AUTO value despite the img->_pixelFormat is equal RGBA8888. In result of that I catch CCASSERT(false, "error: CubeMap texture may be incorrect, failed to convert pixel format data to RGBA8888");
in some lines later.
I set ePixelFmt to RGBA8888 forcibly and the initializing passed well.
The second question touches of the RenderTexture class.
I created custom RenderTextureCustom which based on cocos2d::RenderTexture. It supports rendering to the texture of 3D objects, and can support optionally only depth attachment if needed (without color attachment).
I have the issue on Window in the following sequence steps
first step: Rendering to FrameBuffer with only depth attachment texture;
second step: Rendering to FrameBuffer with only color attachment texture.
issue: No any color data in the color attachment texture after second step.
After some research I found that there is color attachment disabling in the backend/opengl/CommandBufferGL.cpp inside CommandBufferGL::applyRenderPassDescriptor, if color attachment is absent for FrameBuffer (first step). But there is no color attachment enabling after that which cause to the issue I mentioned.
I fixed this with following lines inside the same function:
first step: It will create an FBO and adds a depthAttachmentTexture;
second step: Since the FBO has always created in the first step, so it simply adds a colorAttachmentTexture to the FBO if you want to render it to a texture.
So why there is no color attachment enabling? Or can you provide me a demo?