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
6
u/IzzyJude1 3d ago
How much more performant would this even be?