Congratulations @zhangxm @coulsonwang @PatriceJiang. The team worked so hard in this release.
Everyone, please join me in thanking the team.
Nice.
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?
Yep, but because of metal support, the rendering mechanism changes, and it may fix many rendering bugs that using global GL state.
Congratulations!!!
Few questions:
- Do you have any performance tests to compare v4 vs v3 renderer? (I am interested mainly in iOS, Android)
- Will you close branch v3 and continue development in v4 only?
Is there any rendering performance gain on Apple products in v4 using Metal over v3 using OpenGL?
Would be interested to see any performance metrics.
Congratulations
Congratulations. Thanks for the hard work.
Congradulations guys! ) Thanks for all the hard work! )
Congratulations
Though its have some major issues about metal, like its crashing if device doesn’t support metal.
Thank you.
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.
The new requirements will be ‘Metal-supported iOS device: iPhone 5S or newer, iPad Air or newer’ (see https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html)
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)
Congratulation to the entire team!
Everyone here appreciates how hard it is to work on such a complex project!
Thanks for this release, guys!
My Congratulation!
But could you please clarify some things:
-
The following part of TextureCube::init function:
backend::PixelFormat ePixelFmt; unsigned char* pData = getImageData(img, ePixelFmt); uint8_t *cData = nullptr; uint8_t *useData = pData;
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:
I would appreciate if you suggest something better.
And one more question. Have you in plan to support multiple color attachments?
@nirobkuet @Guykun v3 is still available. And v4 only supports metal is known if you focus other versions such alpha, beta, rc0 …
@coulsonwang pleas take a look of @solan’s issue.
Congratulations. Thanks for your hard work. But why JSB was removed?
- 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
colorAttachmentTextureto 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?
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.)
Example:
RenderTexture_1::onBegin() → set new depth/color/stencil values for _renderPassDescriptor
Renderer::drawXXXXCommand()
Renderer::drawXXXXCommand()
…
RenderTexture_1::onEnd() → set old depth/color/stencil values for render->_renderPassDescriptor
RenderTexture_2::onBegin() → set new depth/color/stencil values for _renderPassDescriptor
Renderer::drawXXXXCommand()
Renderer::drawXXXXCommand()
…
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
Renderer::drawCustomCommand(command)
Renderer::drawCustomCommand(command)
…
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).