I really really really want to use Godot, but sadly, the support for web exports just isn't there in Godot 4:<p>- Can't use C# at all<p>- Has issues running on MacOS / iOS<p>Meanwhile as much as Unity irritates me, they're working on even better web platform support in Unity 6 and smaller runtime bundled deployments.<p><a href="https://unity.com/solutions/web" rel="nofollow">https://unity.com/solutions/web</a><p>I think if I was predominantly focused on traditional console/platform gaming it would be a different story.
This adds more to the evidence that Vulkan / DX12 seems like a failed API design, when too many graphics engineers are reinventing the wheel by building their render-graph API on top of these (propietary triple-A game engines, Unreal Engine, and now Godot...) Instead of real-time graphics APIs providing all these low-level manual synchronization primitives and cumbersome PSOs, maybe they should just provide an official Render Graph API instead? Provide all of the operations and its dependencies in an acyclic graph up-front, and the driver handles synchronization automatically in the most performant manner tailored to the hardware.<p>I guess there needed some trial-and-error in the gamedev world for about a decade to really nail down a nice to use but also performant graphics API design. Vulkan being originated from the Mantle API from AMD didn't help - since it was a low-level console API mainly accustomed to AMD's GPUs and really didn't seem like it would fit for a more "general-purpose" API spanning a huge range of hardware and can stand the test of time. And with Microsoft's DX12 hastely copying from AMD's initial design it also has all the same issues (The irony is that DX11 is still the best graphics API you can use in gamedev in Windows in terms of ergonomics and even performance - seeing many trying to dauntingly build a DX12 backend and end up performing worse than DX11...)<p>Nowadays I'm obversing that the industry has known these issues for a while and are experimenting with alternative API designs... there are some experiental render-graph extensions available in both DX12 / Vulkan (albeit in a limited fashion):<p>- DX12's Work Graph API as preview (<a href="https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre" rel="nofollow">https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre</a>...)<p>- Vulkan's VK_AMDX_shader_enqueue extension (<a href="https://gpuopen.com/gpu-work-graphs-in-vulkan/" rel="nofollow">https://gpuopen.com/gpu-work-graphs-in-vulkan/</a>)
I like the dedication behind godot. Since unity can be a hassle to get to work on linux i might try out their solution.<p>On a tangential note: I am also excited to see whether Embark Studios will open source their engine once it's ready.
It's great that Godot keeps improving. AFAIK it is still mostly for indie devs though. I don't know why valve isn't open sourcing Source 2. They barely even make games anymore and it would make them money in the long term if it means games could be made cheaper and better. UE5 on the other hand is leaps and bounds greater than both Source 2 and Godot judging from the few games that have released with it so far. There's also O3DE which last I checked isn't ready.
Good to hear that Godot is addressing this. The Rust graphics crates are bottlenecking on buffer management. I'm seeing the render thread become compute-bound on a static scene, with the GPU under 25% busy. Stack is Rend3/WGPU/Vulkan/X11/Linux.<p>The latest round of WGPU improvements now has copying content into the GPU memory concurrent with rendering. That level of synchronization has been fixed. But it's still too slow.<p>I dread having to learn how things work down at that level.<p>By the way, what's the thread situation in WASM now? Previously, it was multiprocess with some shared memory, not real threads. Various real threading proposals were floating around. Did that happen yet?
> The order of execution of the recorded commands inside a command buffer is NOT guaranteed to complete in the order they were submitted: the GPU can reorder these commands in whatever order it thinks is best to complete the job as quickly as possible.<p>It's my understanding that commands inside of a command buffer are guaranteed to complete in order. The synchronization must happen when you are `vkQueueSubmit`ing multiple command buffers, no? I think that's what they meant to say?