Apple announcing the deprecation of OpenGL ES in iOS 12 has some effects on the future of Cocos2d-x and Cocos Creator.
The deprecation means:
What should be done technically in the engine to support Metal? How it’s complicated? What exactly should be done, technically? Any ETA about each? Again I just want to understand what should I do with my game…
Well Metal will be supported before OpenGL is depreated… So I don’t know if there is any change at all. Continue using the engine.
No ETA yet, we just decided a plan yesterday. Let’s let the engineers have some to wrap their head around everything.
If you have any custom OpenGL in your apps, I would suggest looking at how you want to handle those.
That’s the main problem, I’m using shaders(with help of other programmers) and I don’t know how to convert(should be done?) and can’t do this because engine is not supporting… so I can’t do anything for now in my game, until cocos2d-x start supporting Metal so I can proceed with fixing and modifying my code. Also, I want to be sure of using a stable code… and a new modifications to the engine should bring a lot of bugs and problems, and so even better choice to release game with deprecated OpengGL probably.
For me the main conclusion is - engine should support Metal - like right now, for survive in the future. I hope this is n1 task for all cocos2d-x developers now. Also, I’m worried because of no any technical info was shared and any analysis of this problem…
Great news that’s likely a sign of relief for a lot of developers rushing here in search for answers! Glad that the engineering team understands the gravity of the announcement.
My only two cents on this is that I hope that there will be a guide or simple way to transition the graphics backend from older versions of v3.X, best case would be a drop-in-place replacement for the renderer.
I believe like ourselves many developers have made modification to the engine source, or have complicated project setups and usually refrain from moving their code to new versions of cocos2dx (which is pretty much a ‘porting’ process at the moment), however this will be one that is critical to near all developers maintaining or developing active apps. I’d really appreciate this being considered as an important point as this transition will be non-optional for all users of cocos2dx
@slackmoehrle frankly speaking: how do you understand a complexity of the rewriting all places in the code and replacing support of Metal there? I’m assuming your are not technical guy? Because no technical answers were provided. However, can someone from the engineers speak here? Clarify something deeply from technical side? Because currently, it’s still no real info… Like you say - everything gonna be alright… but I’m taking a high risk by hiring&paying for my game development(artist & programmers) in cocos2d-x, so now I should think a lot about this…
There are not any technical answers yet.
Here is the timeline thus far:
I’m sorry, there are not any details yet. The engineers dont know yet either. The decision was just made less than 24 hours ago. So there is no update. No ETA. No roadmap. As the team works on this you can be assured we will post here to communicate the status. Pay attention to GitHub also. You will see the commits going in and you can start testing.
In order to support metal we will need to replace all the opengl related API calls with a cross platform API as well as the shader code. The most impact to the developer who has customized shader code. Bgfx looks like a attractive option, unfortunately it doesn’t support vulkan yet. But using it seems like the fastest option. Just my personal opinion.
I like your bullet points and I don’t understand the developers / project owners / whatever who are asking for release dates of 3.18 with metal support.
Sure, a company has to see the big picture for a game, but iOS 12 and macOS 10.14 will be able to use OpenGL for at least one year after the release in autumn.
So everyone who is making panic, should calm down. The cocos2d-x developers are working on it with priority one (I guess) and we can only wait for a release candidate.
Well Slackmoehrle is right no need to freak out. I believe in the end it will be as simple as setting resolution policy now. Like “Renderer::mode(RenderMode::METAL);”. Anyways this all will take time and hopefully apple will give enough.
Would this change enable cocos to publish more on different platforms like lets say Switch? I am looking forward to these changes.
It’s possible but for Switch it is more complicated.
The simplest way to support metal is using metal to implement OpenGL ES API, then no any engine codes should be changed. And i found moltengl, but it is not free. I am not sure if there is other solution. Doing the same thing by us will take a long time, so i think it is not a good idea for us to do it like this.
Another solution is that we should design a new renderer to support multiple back end, including metal. This way will modify the engine, but will not change the engine API.
The second solution is better, I think.
This one is free, and newer, and becoming something. Perhaps.
https://www.anandtech.com/show/12465/khronos-group-extends-vulkan-portability-with-opensource
But this one is not for OpenGL ES, and they are the same author.
OpenGL is of no use.
This is Vulkan, but wrapped for Metal.
Rewrite your renderer for Vulkan, and use Molten, and you can target just about every platform, and Vulkan is easier to port OpenGL renderers to. Even OpenGL ES, than porting to Metal.
MoltenVK is a runtime library that maps Vulkan to Apple’s Metal graphics framework on iOS and macOS. With MoltenVK, you get the performance benefits and added debugging and performance tuning capabilities of the Metal framework on iOS and macOS, without having to rewrite your app that already uses Vulkan, the next-generation open-standard API for high performance GPU acceleration.
By building your application or game using the Vulkan API, you can run your modern graphics application or game unchanged across an entire industry of platforms and development tools.
Look at it this way, you were probably going to need to write a Vulkan renderer at some point, now it serves two purposes, Apple and Android. And PC, and Mac.
So… FOUR. Maybe even Linux. But don’t tell them. They’ll come running.