Yep, this is another way and sounds good. But i think OpenGL ES is needed for a long time, because there devices doesn’t support metal or Vulkan. So multiple back end support is also needed.
2 Likes
Why do they mention vulkan and metal everywhere (github, website, docs):
https://bkaradzic.github.io/bgfx/bgfx.html?highlight=vulkan#_CPPv2N4bgfx12RendererType6VulkanE
Pros and cons, Imho
vulkan + molten - You add a renderer
pros:
- Best strategical solution in a long span; it’s the most obvious market solution and has Valve and Khronos at its back
cons:
- a whole new renderer to write. it’s a lot of work
- you need to differentiate for keeping your open gl renderers for uncompliant devices.
bgfx - you use a specific solution
pros:
- one-size-fits-all rendering solution. metal rendering is direct
- almost all done, it should be less work than vulkan solution
- dedicated community
cons:
- it’s a specific rendering paradigm, you may have to overhaul the engine architecture
- little community
- no vulkan renderer
In short I see a consistent number of guys going the vulkan route (60-70%), with the rest using their own solutions or something like bgfx.
1 Like
So OpenGL is deperaced, at least for Apple. So do we really need its support on other platforms? On Windows/Linux (In fact, linux is also PC, isn’t it?) vulkan is already aviable (in most cases). I think that (I know, it is really hard, but something to do is required) most elegant way is to write wrap around diferrent render systems (like GLView-impl now).
General pros:
- Do it in way that is easier for calling (make it complicated or not, etc)
- Pretty easy to add new render systems (e.g. implement vulkan later, only openGL and molten for now).
Cons:
- It will require more time than making metal-to-opengl bridge
So probably as quick-and-dirty solution porting molten to opengl API is ok, but writing cocos own render API can be done is separated branch.
@zhangxm Cocos2d-x Developer
Hello,
What company resources do you have for doing any of proposed rework?
Any average ETA’s about this?
Regards
2 Likes
So approximately how much time it will take to add Vulkan on Android on cocos2dx? Year or two
Why do you want to force the Android build to Vulkan. Just switching from OpenGL to Vulkan doesn’t do the magic. If you would write your own Vulkan engine, you could gain more speed, but not with a generic one (like cocos2d-x, Unity, Unreal, whatever).
The main problem right now is that Apple will remove OpenGL in one of the next iOS releases and not Google. Another important point is, that currently only 37% (source https://developer.android.com/about/dashboards/) of all Android devices with PlayStore will be able to use Vulkan. That’s why isn’t not a good choice to already remove OpenGL from cocos2d-x.
I am asking because while I learn OpenGL probably it will be more than 37% of devices that run Vulkan.
As @mars3142 said, Vulkan support is not so urgent. Right now, we will support metal first, after doing it, we will have more experience to support Vulkan. So, yep, Vulkan supporting will be one year or two years, and metal supporting i think it will takes months. I can not give you the exact time, but i think it will be ready in this year.
7 Likes
@zhangxm
Hello.
You and cocos engineers are programming master but I have a proposition for you.
If you don’t change any line of rendering code in OpenGL ES at all then all projects is backward compatible, and any custom OpenGL and Shader code in any projects works. (like in my project).
Then write all Metal rendering code from scratch. (Metal written by C++ and very clean if I’m not wrong). I mean rewrite transformation matrix and all rendering stuff for something like sprite. and by preprocessor code we have some sprites creating by Metal or by OpenGL. I know this is very complicated and time consuming. This approach is far from cross platform rendering like bgfx. If you are supporting core Metal API, someone like me can implement some custom Metal code and Metal shader (like OpenGL code in my project). Many of us use cocos because it’s open source and we have full control and can implement our custom code. I like this feature in Metal supported version of cocos (and Vulcan in future).
Best Regards.
1 Like
Did you mean we should do two things:
- first, use metal to implement OpenGL ES API
- second design a new renderer from scratch
I like this idea, but i don’t think we have enough resource to do these things at the same time.
Hi. @zhangxm
Yes, Design a new METAL renderer from scratch and not change any of OpenGL API in previous version. cocos2d-x renderer is stable enough for OpenGL ES2 and you can stop supporting it (like Apple). Android projects (and Win32) can use it for some years (2 or 3) and the new fresh Metal renderer with all core Metal API support iOS and Mac projects.
And later you can deprecate OpenGL ES and Add new Vulcan Renderer for android (and desktop).
I don’t like cross platform renderer with some level of indirection to do all graphic stuff (like Unity if I’m not wrong) but you are the Boss! 
1 Like
But if want to support metal, vulkan at the same time in future, then we need some level of indirection too. And if new version of cocos2d-x only supports iOS or Mac, then i think it is not a good idea.
1 Like
I found google nxt is a good start point. It is designed for webgpu, but i think we have the same goal, working for next graphic API(metal, vulkan).
Why not go with bgfx?
This was something proposed by Ricardo Quesada 2+ years ago.
I think it would have lots of advantages:
-
It supports multiple apis (including Metal).
-
Frees resources from the cocos2d-x team since they won’t have to maintain the rendering backend.
-
It’s open source so eventually, if needed, cocos2d-x team could make any changes it wants to it.
2 Likes
I was thinking about it more even though i was also thinking "why not use bgtx or SDL2 "
this can introduce more problems as it will force the cocos team to modify the rendering engine when problems will appear or wait for fixes in engine that is not their this is sometimes very problematic .
now i think they should add simple interface to the Metal infrastructure as they did with OpenGL
1 Like
There’s this sokol here that implemented metal rendering… I’ve tried on Mac and it appears to work. Didn’t tried on ios…
1 Like
He means that we will support metal first, before we tackle others. There isn’t a branch started for this work yet.
don’t feed the troll