Godot 3's renderer design
godotengine.org
godotengine.org
tl;dr "At the end of the day, the use case where Vulkan and DirectX12 make the most sense is when you have hundreds of thousands of objects, which are all different (different geometry, textures, etc.), and which move. This is a difficult use case to achieve, even willingly."
And android. I.e. everything but Mac OS, iOS.
It is not available on Sony and Microsoft consoles, UWP apps.
On the Nintendo Switch there is NVAPI, which provides even more low level control.
Even worse, Apple's GL drivers never performed very well to begin with. Their intel drivers have been much slower than Mesa for more than half a decade, and supported fewer (super useful) extensions for about two years.
Middleware makes the actual APIs kind of irrelevant.
Also there is no OpenGL or Vulkan on majority of game consoles. Even on Switch, Nintendo still has their own API with much more lowere level control than Vulkan, just in case.
FWIW the PS3 (among others) actually offered OpenGL, not that you'd want to use it (the implementation was pretty bad - Apple-quality).
You can also theoretically run OpenGL code on the PS4 or XBox One if you want to, since they use well-understood AMD GPUs. Fail0verflow has already booted real OpenGL on hacked PS4s (via Mesa, I believe).
You can also run OpenGL on some platforms by using ANGLE to emulate specific versions of OpenGL on top of other APIs.
So, ultimately the "there is no OpenGL or Vulkan" observation isn't that meaningful - if your codebase is built around OpenGL, that's not necessarily a problem at all.
I don't know if I'd bother, but I'd also put money on it being possible to run ANGLE or Mesa GL on top of the PS4 graphics stack (I'm familiar with it).
As for the rest of your examples, they are workarounds, not official support, which means extra development cost when problems arise.
DirectX, PSGL, NVNAPI, and Metal are already available where Vulkan will probably never be.
Agreed that this is a sad state and has been for years. Hopefully we'll see an open source solution to Vulkan->Metal compatibility.
[0]: https://www.khronos.org/registry/OpenGL/extensions/APPLE/
For now, OpenGL ES 3.0 is the closest thing we have to a universal standard. Sadly, compute shaders weren't included until 3.1 so your options for cross-platform GPU compute are OpenCL 1.2 or OpenGL ES 3.0 with transform feedback.
Also on FreeBSD :) https://github.com/myfreeweb/freebsd-ports-dank#mesa-with-vu...
Both APIs are harder to use however and it's quite possible to end up less efficient than older APIs by using them badly plus current implementations can be poor, especially on mobile, so there are still good reasons not to use them.
Well, I don't think it's architected in any way that would prevent the adoption of lower level APIs; but Godot's main markets are mobile, embedded, and web where OpenGL ES 3.0 is a low (but not the lowest) common denominator.
Android apps like Firefox or Dolphin already have a bunch of one-off workarounds for shader compiler bugs, etc. It's worse without a smart driver. On the other hand, the SPIR-V system used for shaders in Vulkan routes around a significant portion of bad shader compilers, so that's nice :)
If you have a Vulkan app that's not tuned for your specific device, your battery life (and framerates) could easily end up worse.
Vulkan and D3D12 shine in the hands of a company like EA or Ubisoft, and it's no coincidence that the Mantle spec (a precursor to Vulkan and D3D12) was basically completely designed by DICE, the developers of EA's Frostbite engine.
While it may be possible for GL stacks to do this, real mobile and embedded GL stacks tend to barely function at all. I highly doubt they do much more than try to extract maximum straight line performance for synthetic benchmarks within their budget.
The reason Vulkan can have an outsize effect on power consumption is that it can allow renderer work to be spread across several threads. Running two cores at 60% the clock rate will typically cost considerably less power than running one at a higher frequency.
This is an explicit (and accomplished) goal of mobile vendors in supporting Vulkan.
Vulkan/DX12/Metal make more sense in many ways, not just to draw thousands of different objects. For one, they allow explicit control on the memory transfers and synchronization, which leads to less performance hitches and and spikes, more predictable and stable framerate.
"Added to that fact, Vulkan still has years to go until it's properly supported in most desktop and mobile platforms, which makes it unattractive to implement for us (as it means considerably more effort to write, debug and maintain). As for DirectX12, it's only relevant for Windows/UWP, so there is no strong incentive for us to support it as a cross-platform engine."
DirectX12 is also relevant on XB1, where you get not many other alternatives. Would be nice to see Godot titles running on consoles, eventually.
That being said, people are achieving some really nice visuals in Godot 3.0 using the PBR shader and new renderer...
In a separate discussion, will we ever see any sort of UDP support in the browser for client/server games?
https://gafferongames.com/post/why_cant_i_send_udp_packets_f...
"while WebRTC makes it easy to send unreliable-unordered data from one browser to another, it falls down when data needs to be sent between a browser and a dedicated server...It falls down because WebRTC is extremely complex. This complexity is understandable, being designed primarily to support peer-to-peer communication between browsers, WebRTC needs STUN, ICE and TURN support for NAT traversal and packet forwarding in the worst case."
Given your experience with WebRTC stcredzero, do you think it is possible to wrap WebRTC in a class to emulate UDP? What is the hold up?
The SimplePeer library works very well to hide the complexity of WebRTC. It works just fine for me. The big sticking point is the complexity/overhead of the setup. This might be mitigated by using the true headless modes in Chromium and Firefox. Given what I remember from installing dependencies, it should be possible to create a fairly lightweight headless fork that only has just enough to run WebRTC datachannels.
So, if you don't need lots of scaling and can deal with the overhead, there is no hold-up right this moment. It's just a matter of motivation.
Any idea what are they going to use?
However, compared to parent:
> GDScript will always be the main supported language, and our recommended choice for all Godot users.
> To clarify things: since the Mono runtime is relatively heavy, and many Godot users will prefer to stick to GDScript, we intend to provide the Mono-enabled version of Godot as a separate download.
They're also adding their version of visual scripting...
Personally, I find GDScript quite OK since you can treat it just like Python, and I think there are some interfaces that enable you to use real Python in Godot (check out their blog).
I tried to find this out, but the one "benchmark" I found was somewhat dubious. The Godot documentation claims that GDScript has all sorts of advantages over using other scripting languages that sound qualitatively superior, but it lacks quantitative comparisons.
The advantage of GDScript is that all its primitives are the same as the C++ primitives that lie underneath. It's memory management model is the same as the engine's, etc... A GDScript function is a C++ function. GDScript is completely integrated into the engine, so if you're doing typical game-dev sort of things, there's literally no overhead.
It's not going away, it'll still be in 3.0 and probably forever after. Just in 3.0 you have the option of C#, as well as C, C++, D, Nim, and others if using GDNative.
Edit - if it's for your kids, there's also going to be visual scripting in 3.0 (which basically is the same as GDScript, in visual form).
[0] https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry...
I like specially the architecture decision of a separate render process.