using native extension just to use whatever graphics api kinda beats the purpose of using defold, imho.
as it is, defold is simple and elegant. makes a lot possible, thanks to rendering scripts, without getting in the way too much. if transition to vulkan will force those scripts to be a lot more high-level (not sure how to interpret “more modern rendering constructs” from the blog entry), it may very well make it useless in some cases. personally, i wouldn’t mind as much direct opengl es access from the rendering api as possible. in case of vulkan, that’s pretty much out of the question - far too easy to blow up the whole engine.
also, i surely hope it’s not a rewrite and more of an additional option. when you want feature parity, it surely is a problem in case of es 3.0, but as it is, on many (already kinda old) android devices, as well as on any half-decent d3d11-capable pc, es 3.0 will just work.
perhaps it’s worthy of entirely new topic, but i’ll just continue here, hoping someone will barge in and answer. from what i’ve read, “more modern rendering constructs” and basically revamped rendering api are one thing that’s coming, but at the same time, glsl shaders will still be in use and translated to spir-v - does it mean vulkan will be an option? would make sense, since many android devices lack vulkan support (there’s a huge market fragmentation after all and you just can’t count on “it’s mandatory in 64bit devices running android 10”). but that raises the question, what is the future for opengl es in defold, and what is the future for current rendering api? will it be deprecated, breaking backward compatibility? because that would be a bad move on far too many levels. and if it won’t be deprecated, and new rendering constructs will be an addition to current rendering api, does it mean opengl es and vulkan will be both first class targets in the future, with option to choose one or the other? with perhaps some parts of rendering api requiring vulkan and the rest working on both targets?
if so, wouldn’t it make sense to have feature parity between opengl es 3.x and vulkan, basically having 3 targets - es 2.0, es 3.0 and vulkan? es 3.0 works through angle on pc (even in cases vulkan doesn’t), es 3.x is already quite popular in the android world (more so than es 2.0 and far more so than vulkan), all that remains is… apple.
but that makes me wonder, is apple actually the reason behind moving on to vulkan?
there’s moltengl, but that supports es 2.0 only, so the only other solution than going vulkan for apple i can think of, is some weird frankenstein-alike merge of angle and moltenvk (wrapper over wrapper)… or sticking to es 3.0, which is supported and won’t be dropped anytime soon. the bad thing is, it’s unlikely apple will push es 3.x support going forward, so stuff like compute shaders or tesselation wouldn’t be possible even in the future. and in general, sticking to opengl es in case of apple is obviously an unsafe option.
but that rises the question, is angle over moltenvk really a crazy idea? es 3.x drivers in the android world are far from being perfect, so if defold would want to utilize es 3.x capabilities, angle is a good way to go there - es 3.1 support over vulkan is a work in progress, es 3.2 support is planned. as it is, angle provides es 3.0 on pc (via d3d11/vulkan), es 3.1 on linux/osx (via opengl), es 3.x support on android (and osx/ios via angle over moltenvk) would start working when angle goes out of “work in progress” stage in that area - but es 3.0 works as it is on ios and android already.
so basically, going with angle everywhere (and frankenstein angle over moltenvk in case of apple - but that could be delayed, since as it is, es 3.0 works there already) would be both easy and future-proof. google has interest in developing angle, since it shields es 3.x apps from badly written drivers on vulkan-capable smartphones. besides, web browsers use angle widely, so it’s just next to impossible that library will die, just like opengl es won’t die.
and vulkan… don’t get me wrong. as long as it’s just one of the targets, with both es 2.0 and es 3.0 being available, it’s all good. if it means there won’t be an es 3.0 target, that’s not so good, because there’s plenty of hardware (in both pc and android worlds), that’s es 3.x capable and that’s incompatible with vulkan at the same time.
but in general, going vulkan is both an overkill and opening a can of worms, imho. overkill, because performance benefits of using vulkan can be seen only in case of AAA titles created by teams of talented developers - and they won’t be using defold. defold simply has no interest in chasing unity or unreal, but that’s not a bad thing. there’s both a beauty and value in having smaller engine not getting in a way while providing lowlevel-friendly access to many things. easily programmable pipeline is something extremely valuable and in case of bigger engines things that should be simple, are often possible but you gotta jump across far too many hops across the way to make it worthwhile. such engines impose limits on developers because of how complex they are, and that’s something i’m afraid may become reality for defold after switching to vulkan - because it may be either that, or a can of bugs in both the engine and user code.
a few years from now, with vulkan widely adopted in both android and pc world, it may sound like vulkan could be a viable choice as the only supported target - but that’s far from reality, imho. we’re in 2019 and still over 40% of android devices is below android 7.0, while android 10 will require vulkan support only for 64bit smartphones, leaving lowend devices free to support opengl es only. on top of that, according to some developers chipset vendors still do their thing and their vulkan drivers are simply bad, so… when you tell me the engine is being rewritten for vulkan, it makes me wanna run from it as far as possible.