Disclaimer This is just some person talking. This is not an official statement, plan of action, etc. Disclaimer
What if Cocos2d-x switched to bgfx?
What does removing OpenGL mean for the engine. technically? How would drawing a Sprite change?
1 Like
Obviously bgfx would take over the job of our current renderer. bgfx is cross platform so it makes the rendering piece platform agnostic where you put it on top of a backend, lke Metal, DirectX, etc.
I suggest you to change the topic to bgfx VS sdl2
they both great but sdl2 have much more mileage in the gaming industry and not support metal also
Why does cocos still insist to do its own render ? using one will save you man years of working and you could
Invest in monetizing and improving
1 Like
Well we may not have a choice anymore with yesterdays announcement.
Okay… but why you asking here? Where is officiall cocos2d-x developers-engineers-programmers who can comment this and also familiar with: shaders, OpenGl, Metal, Vulkan and other cool things, so they can bring a bit technical information and details or possibilities to make this more clear? Because currently I don’t understand a problem… but I understand that it exists.
By the way, who is currently pro-opengl dev for cococ?
@slackmoehrle
Business wise i think you should have do it long time ago …
Stop Over engineer the engine , just improve it .
Use the resources you have already as open source render
We have a diverse community. Helping see how others might solve problems leads to greater understanding and success.
Not knowing anything about how OpenGL or other renderers work on the back end of the engine, I’m curious if switching it to SDL, bgfx or something else would make it easier to support consoles like say Nintendo Switch? I always kind of assumed that is what was holding off support for them. If so, I’d say that’s another advantage of switching.
2 Likes
Using bgfx or some other API layer would have the added benefit of reducing the resources required to maintain that aspect of Cocos2d-x. Whether or not something is forcing Cocos2d-x to switch over to using such an API, it’s a good move regardless, with more benefits down the track, like supporting new rendering backends when they are released without having to change code in Cocos2d-x.
The same goes for any other aspect of Cocos2d-x that can be handled by a separately maintained library.
@Meir_yanovich This should not be a discussion about SDL2 vs bgfx, because bgfx is not a replacement for SDL. Both can be used together, each addressing a specific requirement, and there are projects around that do use both.
1 Like
SDL only has a very basic rendering API (by design) so it wouldn’t be a suitable replacement in that regard, but it does provide a very portable and very well battle tested platform abstraction for other areas like windowing and input.
BGFX would be a great replacement renderer IMO. In fact, the Swift offshoot of cocos-objc, Fiber2D, uses BGFX at the core.
Another to possibly consider is Kore, which provides platform abstraction for windowing, input, graphics, sound … everything.
You’d need to keep the Cocos rendering code dealing with draw call reordering with Kore, not so with BGFX. Both also provide compute and tesselation shaders if the platform supports it.
Cocos engine on top of one of these layers would be a winner 
1 Like
I’m currently interested only in official comments, for sure many members can advise something interesting any time. But… they(both members and cocos2d-x engineers specially) should really hurry… because it’s now very serious for any developer who using cocos2d-x which is NOT supporting Metal and will NOT be able to do games in future for iOS, lets say for iOS 13. And so, it’s just with in 1 year since now. I hope you will update us with some really official news and decisions.
Dose bgfx support vulkan?
from https://github.com/bkaradzic/bgfx
nothing about Vulcan or moltenVK.
See the tag list of the project 
Thanks, Now I see it. but I love to see Vulkan in cocos2d-x render pipeline. if I’m not wrong android 7+ support Vulkan.
@nivrig
i think that the “basic” API is what is needed for cocos engine it is already become bloated it needs to be much
thinner more cocos 2d’sh back to version 2 size .
@R101
why to use both ? can you explain ? why not just SDL?
Slso peeking such major component needs to take consideration the proven track record of the lib
how much its bean develop , how much support it have , how easy it can be to change .
How fast it update patches , how do the API changes from version to version
and the license .
The SDL render API is really only for solid coloured primitives and textured rectangles. There’s no shader support or general polygon rendering for instance, and it makes no efforts to be clever about avoiding redundant state changes or batching so it can be quite slow (especially on DX11 I’ve found).
It’s fine if all you’re doing is sprite games but you’ll need something else for anything beyond that.
1 Like
BGFX does not support Vulkan, but it does have a native Metal back end.
1 Like
Weird. But the tagline clearly shows Vulkan. Thanks for the link.
This thread discusses that exact question as to why you can use both (you don’t have to use both, but the option is there): [question] Can the render be used as replacment to SDL2 / GLFW ? on ios / desktop / Qt render? · Issue #738 · bkaradzic/bgfx · GitHub