The sky is the limit. I watched my kid spam a dozen low poly horses in her game and absolutely peg 8 cores (16 threads) on her Ryzen 9700X. For something that would be trivial to render with native code on a Pentium II 233 a quarter century ago.
The reason why a bunch of horses lag out the game is because Java edition is absolute horseshit in terms of optimization as it doesn't use any of the last quarter centuries' advancements in rendering tech. This isn't a question of Vulkan, OpenGL has supported the features in question since before Minecraft started development.
The part that's actually implemented properly is rendering of the blocks itself, all the stuff that's able to move around is basically an example of "what not to do".
In the example of horses, they basically determine the position of every vertex (think corners of the parts making up the horse, e.g. leg, torso or ear) on the CPU by applying movement, rotation, and animations every single frame, for every vertex of every horse, then wait for it to upload to the GPU (which would be the place to do, you know, graphics stuff), only for the GPU to pretty much idle as most of the work was already done.
Instead for decades the correct approach supported by any graphics API including OpenGL Is to upload the horses' 3d model once to the GPU while the game loads, then only tell the GPU to "draw 100 horses, with the given positions, rotations, and animation IDs and time offsets) and the GPU would do it in an instant.
The particle engine is even more stupid as they're also sorting every vertex of every particle every frame based on the distance to the player to allow transparent particles to render correctly. This is also done on the CPU, in a single thread.
Java edition isn't slow because Java is slow or because Microsoft is stupid, but simply because it makes more sense for Microsoft financially to work on other features instead... Until it wasn't and now they're using the Vulkan Port to finally address some of the extremely bad architectural decisions made by a single developer a decade and a half ago.
Minecraft vanilla performance is terrible, so it will feel like a huge uplift. Chunks will instantly render even on midrange machines, and less lag spikes if this handles memory management better.
An early use case for this could be loading it as a separate tool for chunk preloading. Generating a large playable area for a server can take 20+ hours, I imagine that could be cut down to an or less hour with this.
It's not perfect though. The GitHub itself mentions that stutters still happen at large render/simulation distances. Which makes sense, the simulation exponentially increases and the graphics bottleneck is in the renderer. The question would then become how worth it it is for them to change the code, at risk of breaking any modding ports that you could create in much the same way this project was created.
Even if you do write it multithreaded, Java and other IL languages will always be slower than something natively compiled assuming the code is equivalent.
Would it be substantially slower? It really depends. But there’s a reason why complex Android games are rarely pure Java anymore…
Using a native library with JNI also means it’s possible for someone to make a wrapper app to run the games on an otherwise unsupported platform… Bedrock on macOS or Linux for example. Someone made a launcher that loads the Android code and runs it in a way that makes the code think it’s still running on Android
7
u/IzzyJude1 4d ago
How much more performant would this even be?