Graphics backend for opengl and metal

Graphics backend for opengl and metal
0

#25

Why not use BGFX/SDL?
In case developing new renderer cocos developers will spent a lot of time for develop and then fix many bugs.
I think it’s much easier and faster to use polished library.


#26

I answered it here. Graphic part is important to an engine, cocos should control it. BGFX is not just a graphic API wrapper, it is a renderer.

Yep, only support metal is not enough for v4. What i mean is that it will break compatibility a lot, and we should not do in v3.x.

Could you please share the experience or add some link here? We want to do as little work as possible to support metal.

The API provided is easy to expand to support vulkan, and we have no plan for DX12, we can use OpenGL or vulkan on windows.


#27

Sounds good on all comments.
Your path forward seems to be good based on your feedback.

I think the only thing I’ll reiterate is that since you can use Vulkan on Windows, Android, and Linux then I would maybe suggest writing a cocos2d-x custom Vulkan renderer. Then use MoltenVK to support iOS/Mac since it is an open source thin wrapper around Metal. Keep the current OpenGL ES renderer and write any code necessary to have the old GL rendering code conform to the new cocos2d-x rendering API that would be chosen as a compiler/#define flag, or whatever.

https://github.com/KhronosGroup/MoltenVK .

Especially since I do know people had issues with OpenGL ES 3.0 (3.1 may have fixed issues) and therefore it probably also doesn’t make much sense to write a ES 3.0 renderer, instead just keep using 2.0 for those who need to build for older devices, and Vulkan for all others.

https://godotengine.org/article/abandoning-gles3-vulkan-and-gles2 .
(not sure if still valid, but I think it makes sense to go Vulkan + existing GLES2)

I guess I just don’t see a great reason for writing a Metal-specific back-end immediately, since OpenGL ES deprecation only means unsupported, but still available (at least through Sept. 2019) and Vulkan, for better or worse, seems to be the common API into the future (likely to see WebGL 3, or renamed WebGPU or whatever, take on a similar command/parallel API as Vulkan, instead of its currently being based on OpenGL ES).

And my final comment is that my main point is just to suggest getting v4 1.0 out the door by focusing on a single rendering backend (whether Vulkan or BGFX/SDL/etc). Afterward a Metal-specific and any other non-required code and features would then be appropriate.

As always, up to your team.


#28

Your suggestion is good, if we do like this, then it may have problem. For example, cocos is written in vulkan in v4, apple delete OpenGL ES and not all android devices support vulkan. Then developers should do like:

  • use v3.x to release for Android devices that doesn’t support vulkan
  • use v4.x to release for other platforms

The problems is that, what APK to release for Android? Is it possible to release 2 APK and select correct one when installing? The other problem is we can’t promise that the API of v3.x and v4.x are the same, then how games can work both with v3.x and v4.x.


#29

[sorry this is long, I’m just throwing out my thoughts, and a reminder that mostly I’m no longer using this engine, but I try to support it as a community and continue to hope for a continued successful future - so don’t take my word for being worth anything]

Yeah I guess I’m just promoting or suggesting work toward an engine for the future, and not current, devices. Therefore a majority of the devices that support Vulkan/Metal will be a reasonably high percentage.

I’m also sort of assuming based on various comments and commits and repositories that have been worked on and created over the past few years that v4.x is going to ultimately be v3.x with some features removed that were not used very much and replace the rendering layer to better support the command-style rendering GPU APIs (Vulkan/Metal/DX12).

Therefore a v3.x game may not need any game-specific code changes, or hopefully at worst only small code changes, to support building the game using the v4.x engine.

In this way there would only be breaking changes at the rendering and shader layer. If a game has written custom OpenGL code, overridden onDraw (et al), or use custom shaders then there would be some amount of code changes or new code/shader to be written for those games.

Possibly also a removal of certain features if they’re not used much, at least from the default library. Maybe also a more componentized build source set up such that one could more easily add, but also disable, a component like Physics support.

Again, it’s also possible that the OpenGL rendering support could still exist in this incremental v4.x engine.

v3.x used when building for older Android devices that don’t support Vulkan.
v4.x used when building for iOS/Mac and those supporting Vulkan.

This is probably my mistake using the terminology “v4.x” for this basically same engine with a new rendering backend, and therefore you could decide to name it v3.20 or whatever and keep it as an incremental build focused only on adding support for Vulkan or Metal.

I think my idea is to maybe clean up some code allowing for some breaking changes, adding the new rendering backend, calling it v4.x and then work on an entirely new game engine (essentially) for v5.x with ECS or whatever other higher-level changes you want to make. Maybe that one is basically cocos-lite focused mostly on the CocosCreator/Javascript engine going into the future.


If instead you plan on v4.x to be a entirely new engine, such as using an entirely different architectures like ECS, or changing the way actions are applied, how memory is managed, how nodes are managed within a scene, etc, then my advice is probably invalid or incomplete.

In that case I guess it probably makes sense to write a Metal rendering backend for v3.x and postponing v4.x engine. My advice could still apply to this v4.x entirely new engine by looking into using an already written graphics rendering library/framework (e.g. BGFX).

(it really just depends on how much time your team plans to put toward the various components and features of each version and programming language)