Though I thought a company large as Microsoft would have the resources to build a cross-platform RHI with the most stable API available for each platform (DX12 for Windows and Metal for macOS)...
The relevant measurement is the resources Mojang has as a studio. And I expect the decision here is that they don’t want to commit to the long term maintenance of three renderer implementations on the Java side.
Another concern is that modding is a major part of why Java Edition is so popular, and that includes shaders specifically. This is already going to cause chaos in the modding world as it is, no need to compound that by making shader mods that much more burdensome to maintain.
Funny to contrast with Bedrock edition, for which they paid for FMOD Studio to cover the audio features of those two (and more).
I suppose, if someone in future might want to create their own godot-alternative. Why not just use bgfx with the language bindings instead.
I Love Godot from my time tinkering with it but one of the reasons why Godot is so hopeful in future compared to other engines is imo the fact that they support many many platforms.
I have seen some blogposts on HN where someone used godot to prototype an android GUI application (and not a game) and how the whole process actually makes sense when you think about where they talked about it in the blog post.
Actually there were discussions about even integrating bgfx into raylib (the goat) but looks like that its not getting integrated but it was interesting to read the discussion and maybe anyone more experienced than me could even contribute to the discussion below
But you can easily make Vulkan run on macOS. Not sure what would be the reason to use DX12 in the new project today given free choice of technology, especially when team comes from OpenGL.
I'm making a joke, but it's also true.
Of course since Proton uses Vulkan to implement DX12, it means that our Vulkan implementation is simply worse than the one that Valve created to emulate DX12.
I'm sure it's possible to improve that, but it implies that there way to get the best performance out of Vulkan is less obvious than the way to get it out of DX12.
The main thread is often the limiting factor in minecraft. Minecraft just can't go as fast as the GPU could render the scene and even with quite a lot of shaders things are CPU bottlenecked. Hopefully this changes with time as modding minecraft could certainly do with a bit more CPU time free.
This makes sense. I guess I’m a bit surprised they were still OpenGL anywhere.
I never really got into Minecraft though, so I can’t pretend I know much about its current state. I didn’t even realize there was a non-Java version for desktops.
Probably the most underappreciated great feature in recent Java releases.
For Vulkan you already ship "pre-compiled" shaders in SPIR-V form. The SPIR-V needs to be compiled to GPU ISA before it can run.
You can't, in general, pre-compile the SPIR-V to GPU ISA because you don't know the target device you're running on until the app launches. You would have to precompile ISA for every GPU you ever plan to run on, for every platform, for every driver version they've ever released that you will run on. Also you need to know when new hardware and drivers come out and have pre-compiled ISA ready for them.
Steam tries to do this. They store pre-compiled ISA tagged with the GPU+Driver+Platform, then ship it to you. Kinda works if they have the shaders for a game compiled for your GPU/Driver/Platform. In reality your cache hit rate will be spotty and plenty of people are going to stutter.
OpenGL/DirectX11 still has this problem too, but it's all hidden in the driver. Drivers would do a lot of heroics to hide compilation stutter. They'd still often fail though and developers had no way to really manage it out outside of some truly disgusting hacks.
But in reality the exhaustive pre-compile will compile way more than will be used by any given game session (on average) and waste lots of time. Also you would have to recompile every time the user upgraded their driver version or changed hardware. And you're likely to churn a lot of customers if you smack them with a 30+ minute loading screen.
Precisely which shaders get used by the game can only be correctly discovered at runtime in many games, it depends on the precise state of the game/renderer and the quality settings and often hardware vendor if there are vendor-specific code paths.
Some games will get QA to play a bunch of the game, or maybe setup automated scripts to fly through all the levels and log which shaders get used. Then that log gets replayed in a startup pre-compile loading screen so you're at least pre-compiling shaders you know will be used.
Steam could improve the experience here by having the shaders compile overnight in the background so it presents zero delay but the current way doesn't bother me much at all.
Really depends on the game.
There's no easy way around this problem. It never came up as much in the OpenGL/D3D11 era because we didn't make as many shaders back then. Shader graphs and letting artists author shaders really opened pandoras box on this problem, but OpenGL was already on its way out by the time these techniques were proliferating so Vulkan gets lumped in as the cause.
Slightly off-topic too, but I would love for Minecraft Java Edition to have a safer and more robust modding API. For the past decade modding efforts have mostly just been patching on top of a reverse engineering mod framework which exposes some of the game to mods. Factorio is practically the Platonic Ideal in this regard with its Lua sandboxing and restricted API. This is a huge security and stability issue, but Microsoft have no real incentive to fix it.
https://learn.microsoft.com/en-us/minecraft/creator/scriptap...
Where does it say that? Why not use MoltenVK?
There is the non-Java version (Bedrock), but that’s not nearly as extensible.
Considering the vast majority of mods are just adding some items or creatures, they don’t need to worry. This won’t be more than the regular API changes in between versions that they’re already used to, unless it’s a more graphics heavy thing like a shader mod.
Also, even with shaders, it’s fairly straight forward to port a shader from OpenGL to Vulkan (for the most part Vulkan just gives more flexibility in that regard). The stuff around it is the hard part.
Now both exist and get roughly the same feature set now, but the Java version remains popular given the vast variety of mods and servers.
> Minecraft: Java Edition runs on Windows, Mac, and Linux; Minecraft: Bedrock Edition runs on Windows.
(From their own website. Bedrock might work with wine etc.)
For a game as popular as Minecraft, where every year a fresh cohort of young players reaches an age suitable for playing it, it would be madness to discard Linux and Mac users and possibly push the modding community to some other game.
There’s a native version called bedrock
This would be termed "Java Minecraft", not "Minecraft Java"
https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine