I hope this reduces the CPU overhead a bit on the main thread with some time. Quite a few games that ported from DX11 to 12 and openGL to Vulkan didn't just gain performance from the API swap it required taking advantage of the new higher parallel draw call capabilities. #
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.
I use Unigine Heaven to benchmark Linux systems. A colleague's friend has an epic spreadsheet of Heaven benchmarks across many configurations, and he submitted a few I've done. I ran it at home on my Linux desktop. For shits and giggles, I also downloaded the Windows version and ran it in Proton, and got a 30% performance boost! I suspect that a lot of that is due to the dxvk library that Proton uses, and the multithreading that it introduces translating D3D11 calls to Vulkan.
I'm aware. I work in ewaste recycling, and most of the machines I come across are about 10 years old. I'm also a fan of JayzTwoCents. https://m.youtube.com/watch?v=ukb5tlT4IuQ
The underlying world representation is chunky voxels, but they get triangulated into meshes for rendering. Unlike say, Teardown, which renders voxels directly.
Minecraft's non-world entities like players and enemies aren't voxels at any level though, those are directly authored as low poly meshes.
Not a bad choice... since Minecraft Java edition only supports desktops, they don't have to deal with the abysmal Vulkan drivers on mobile.
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)...
A company as large as Microsoft has resources to do a lot of things, but you’re not borrowing resources from the Office team to help on this project.
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.
Java garbage collection gets out of control when cramming 100+ poorly optimized mods together. The bedrock edition is great in theory but the proper mod API never appeared. Regardless, people have accomplished some really impressive stuff with commands, but it is an exercise in pain.
The other issue with bedrock is it is far from feature parity with java. If these two things were hit then java could be reasonably retired. However we are decades too late in it being acceptable to introduce a breaking change to mod loading. So it's java forever.
>Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Of course. Because they would fail loudly and would have to be fixed in order to run. Garbage collection is a crutch which lets broken things appear not broken.
Memory leaks very often don't fail loudly. Especially if they are slower leaks which don't immediately break the application.
A lot of the memory problems that you can see without a GC are hard to find and diagnose. Use after free, for example, is very often safe. It only crashes or causes problems sometimes. Same for double free. And they are hard to diagnose because the problems they do create are often observed at a distance. Use after free will silently corrupt some bit of memory somewhere else, what trips up on it might be completely unrelated.
> A lot of the memory problems that you can see without a GC are hard to find and diagnose
The nastiest leak I've ever seen in a C++ production system happened inside the allocator. We had a really hostile allocation pattern that forced the book-keeping structures inside the allocator to grow over time.
To be fair, I've seen something similar with the JVM, though it recovers. G1GC when it was first introduced would create these massive bookkeeping structures in order to run collections. We are talking about off JVM heap memory allocations up to 20% of the JVM heap allocation.
It's since gotten a lot better with JVM updates, so much so that it's not a problem in Java 21 and 25.
> Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Garbage collection does not solve memory leak problems. For example
- keeping a reference too long,
- much more subtle: having a reference to some object inside some closure
will also cause memory leaks in a garbage-collected language.
The proper solution is to consider what you name "poorly optimized mods" to be highly experimental (only those who are of very high quality can be treated differently).
> Garbage collection does not solve memory leak problems
It solves a class of memory leak problems which are much harder to address without the GC. Memory lifetimes.
It's true that you can still create an object that legitimately lives for the duration of the application, nothing solves that.
But what you can't do is allocate something on the heap and forget to free it. Or double free it. Or free it before the actual lifetime has finished.
Those are much trickier problems to solve which experienced C/C++ programmers trip over all the time. It's hard enough to have been the genesis of languages like Java and Rust.
There is no "must use GC" mode, as far as I'm aware, but the footguns you describe only exist if the programmers opt-out of the GC. It's somewhat similar to using JNI/FFM in Java: it's possible to escape the safety of the VM. Though it's much easier to do so in D.
I always had trouble running bedrock as a household server. Specifically it would stop accepting connections and required daily restarts. Java was much more reliable.
Skins, media packs, servers, hosted realms, upsales through all consoles, multiple copies for multiplayer with/between your kids… also a mass revolving shit tumbler of account stuff on the backend that invalidated lots of old accounts…
I bought during the beta for a lifetime of goodies, had to buy it again after the buyout, then again after an update to MS accounts wasn’t acted on, and then for the Switch. I’ve bought Minecraft 4 times, with another on the horizon if it keeps popular.
That was probably their intention, but Bedrock has proven to be full of papercut sized bugs, and maintaining 1:1 behaviour with Java has also proven really difficult. Redstone is notably different/broken with the exception of trivial circuits.
Until it's possible to convert your world to Bedrock and not have anything in your 'finished' world break, except maybe some giant Redstone machine or one or two known annoyanced, I doubt they'd do it. Mojang presumably still has some autonomy within Microsoft so long as the money keeps coming in, and Mojang presumably knows that pushing this too early is a bad idea. But Microsoft being Microslop, who knows, maybe they'll just do it anyway.
I don't think 1:1 behaviour with Java was ever the intent. Redstone works differently due to a combination of different design choices, like not breaking in water (although I can imagine that being an accessibility thing for console players) and less technical debt, making things like movable tile entities possible.
I don't know what you mean by media packs, but the server software is free, and I believe all of the skins and maps released by Mojang itself on Bedrock's marketplace are also free. It's the third-party stuff that costs money, although I assume Mojang takes their cut.
They do have a bunch of add-ons now with Realms notably, but I wonder if this revenue goes to Mojang or to another Microsoft branch for tax reasons. To say nothing of derived media, plushies, Legos etc.
This is such a gold mine project! thanks for sharing it.
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
Honestly pick between Vulkan and DX12 is very superficial.
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 don't think it's faster than a windows game running Vulkan, though, is it? Like, if you benchmarked a game that has native DX12 and Vulkan modes (such as Wolfenstein: The New Colossus, I believe), it will probably have higher FPS in Vulkan mode, right?
Well our game runs faster in DX12 under Proton than Vulkan under Proton.
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.
Vulkan more or less also has that goal, but for then-current hardware 24 years later (2016). In this case (Intel HD Graphics 4400, Haswell?), there is unofficial support on Linux that can be enabled with some hacks, and it may or may not work. Similar support for my previous (desktop) AMD GPU generally worked fine. The situation for Haswell seems more iffy, though.
it looks like "in hardware" it has vulkan 1.0 support, but looking at https://mesamatrix.net the hasvk driver (which i think is the haswell/gen 7 and 8 driver) seems to have some support for more recent extensions
and of course all the previous minecraft versions will continue working on opengl :p
It was a great machine. It was my daily driver until a few years ago. I ran xubuntu on it with the Mr Chromebook firmware for a loooong time until my most commonly used websites became so heavy browsing was impossible.
I got mine first year of college because my 5ish year old 15" mbp was just too much of a boat anchor. I got a launch model with the celeron, 4gb of ram, and no touch screen so the battery life would last all day and then some.
I installed Chrouton which let you switch between chromeOS and a full ubuntu chroot, which was the best of both worlds as you could do the optimized browsing on ChromeOS and development tasks on the chroot.
After it fell out of ChromeOS favor, I just installed arch on it and called it a day. It's my go-to conference laptop because it's still so conveniently small, light, and 12 years on the battery still gets 6 hours.
Time for an upgrade buddy. I need my 32 chunk render distance when i play java, personally. A 10+ year old chromebook would not be cutting it - but it doesn't take much either if your simulation distance is low.
Who would have thought that Microsoft would end up getting cosier with Khronos standards than Apple. This is after they adopted SPIR-V both as a target in their shader compiler and as an ingest format in DirectX, smoothing over interop with Vulkan in both directions.
Microsoft has already been there before as well, they are adopting SPIR-V only to cut down their fork, and because Google already did part of the work for them.
Apple apparently got very pissed on how Khronos took care of OpenCL.
Then Sony and Nintendo couldn't care less about Khronos, people keep forgetting about game consoles when discussing the portability of Khronos APIs, or ignoring the fact that in reality they aren't really that portable due to the extension spaghetti.
Indeed, however OpenGL and Vulkan are mostly for porting purposes, if you want the real device goodies, it is either NVN, or extensions that are only available on Nintendo devices, hardly a difference.
> it's a shame you need mods to have shaders on Java
You don't. Ever since 1.17 you have been able to build GL shaders directly into resource packs. Resource packs don't require any complex loaders and don't pose a malware risk. To install them you can either drag-and-drop them as .zips directly into the resource pack menu, or a server/world can be configured to prompt the installation of a resource pack. These resource pack shaders are not quite as flexible as Aperture, Iris, or Optifine shaders, but they are fairly close in functionality.
I'm curious if they will carry over this functionality for Vulkan shaders embedded into resource packs. I suspect they may not, which is understandable given how it can be used to break the game's functionality much worse than an ordinary resource pack can (not full RCE, though)
This one is particularly interesting because it integrates block data in the rendered world along with some server-side augmented data to render a minimap in a vanilla client: https://github.com/JNNGL/VanillaMinimaps
Also redstone is different, there's no F3 menu, generally far less vanilla customisability, far more micro-transaction prompting, far fewer commands and I'm sure 20 other things that someone who has actually played Bedrock recently could name
This thread is quite weird to me. People are massively overstating how important modding is and understating the strength of vanilla Java. Minecraft is not Skyrim
Speedrunning, anarchy servers, parkour, technical farming, server economy destruction videos and other primarily vanilla Java content forms are as popular as ever or more. Alongside the newer content creators, Hermitcraft is still growing somehow, as is Etho. Besides anarchy a little bit, none of this is reliant on modding
There are significant updates every year and many people, including me, install them every time they come out and play them in vanilla.
Speedrunning is very much modded - ranked (the big content) is just flat out modded (not just the match setup, there are game tweaks too (guaranteed blaze drops after 20 or so iirc, guaranteed dragon perch in ≤3 mins)), and even RSG/SSG/AA/etc have a long list of allowed mods (much quicker seed rerolling, timer, perf improvement mods, etc). Many(/most/all? idk) Many (/most/all? idk) hermits use mods (esp. freecam, replaymod for creating timelapses / pretty camera perspectives). Never mind shaders sprinkled in a portion of everything.
These are minor tweaks. You could remove these and the speedrunning community/HC would lose little. A second account in spectator mode is a slightly less convenient version of freecam and the speedrunning community is kidding themselves in the first place allowing any tweaks to RNG whatsoever. They could ban that tomorrow and there'd be some grumbling but nothing would change viewership-wise
Minor tweaks are still a mod. Gameplay overhaul modpacks that turn the game into Factorio are definitely the a small minority of the playerbase, but anyone who knows better plays with at least some sort of client-side performance mod (Optifine, Lithium, etc), and that's been true since before 1.0.
Etho's dedication to keeping a purely vanilla singleplayer world is a unique feat. If you want to use Hermitcraft as an example of the median SMP, their modlist is actually quite large: https://github.com/henkelmax/hermitcraft-server
Minecraft simply has a lot of areas for improvement that haven't been touched by Mojang for one reason or another, and a big reason why people stick with Java is because the community has built an ecosystem to tweak the game to their liking.
The main actual speedrunning categories don't allow any RNG changes; but I doubt anyone doing RSG would have any interest whatsoever going back to the 20x-or-whatever slower seed rolling, that's just a completely utterly dumb waste of time doing literally nothing except clicking a button every 5 seconds (effectively changing the category from "who can play the game the best" to much more like "who has the most beast of a machine to run as many minecraft instances in parallel to more quickly roll a good seed"). Viewership would definitely go down from there being less actual gameplay.
Ranked is intended to be a fun competitive thing; waiting 10 minutes for a dragon perch doing nothing is Not Fun; waiting forever at a spawner is Not Fun; simple as that, people wouldn't play it if it wasn't fun. (oh, also, I believe Ranked also just generally includes making mob drops consistent for the same seed (and consistent portal locations, and probably other things), without which the whole entire concept of competitively playing the same seed would not work whatsoever, devolving to just who got the better RNG, distinctly Not Fun; also the ability to review a replay of your game afterwards for learning). Viewership and player counts would go down because you'd just be looking at very slow gambling instead of something actually meaningfully-skill-based.
A second account might work for freecam (though it adds more editing work, aka makes you not want to actually use it much), but making pretty timelapses is not feasible that way. Granted, you could still live without it, but the quality of content would undoubtedly go down. The little things go a long, long, long way.
To be clear I do kinda agree with the general idea that modding isn't that important to Minecraft Java; but it's still very important at least indirectly - were there not as large of a modding scene, I'd imagine many more content creators would've long ran out of content to make on it (or at least unique ways to do things), and the technical research/farms/whatever would be hampered by less available tooling.
(for what it's worth, last I played minecraft, like 1-2 years ago, I did so lightly-modded - Do A Barrel Roll for much more fun elytra; lithium; Distant Horizons; Hydrophobic Elytra to fix a stupid extremely-annoying elytra bug (might be fixed now?), BetterF3 (kinda superceded by the more recent F3 overhaul now I suppose?))
I wasn’t aware Java had Vulkan bindings. So this is JNI I’m guessing?
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.
To elaborate on the other comment about the Foreign Function & Memory API: JNI is effectively dead/deprecated, and has been replaced by the aforementioned API. It is orders of magnitude more developer friendly to use. It handles memory much more cleanly. It's way easier to create bindings to talk to foreign functions (e.g. Vulkan).
Probably the most underappreciated great feature in recent Java releases.
It will be a while before JNI itself is dead, because far too much stuff still relies on it. The unsafe helpers in the Java standard library will die first because they are fundamentally incompatible with Valhalla, but it's likely the simple cases will last a while as there are vast swaths of glue code that needs to be rewritten.
IIRC Minecraft is still using entirely JNI and no FFM yet. That will probably start to change in the near future, though. Some modders have already been replacing their own natives with FFM versions.
This is great news. I was super disappointed when Rainbow Six Siege dropped the Vulkan version of their game. They cited the support burden as the reason they dropped it, as nearly every game in the studio defaulted to DX11/12. For at least two years after that they received non-stop complaints of frame stutters on DX12. I do not know if the situation has gotten much better since then.
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.
I don't think Minecraft's renderer will be PSO-heavy enough to have stuttering issues. It's not a state-of-the-art compute-driven renderer that supports artist-driven workflows with custom materials and shaders... it's just a voxel renderer with very primitive lighting.
Vulkan gives all the tools to avoid any "lag spikes" from shader compiling. In fact, causing them is much more difficult than OpenGL where they could happen in surprising places (and only on certain hardware).
The issue is two fold:
1. Some engines produce a lot of shader permutations. Some AAA titles can have 60000 different shaders compiled.
2. Some GPU rasterizer states (such as color blending) are implemented as shader epilogues.
In Vulkan 1.0 almost all of the pipeline state had to be pre-baked into a pipeline state object compiled ahead of time. This lead to a "shader permutation explosion" where different states need different pipelines.
This requires the game engine to either a) compile all the pipeline combinations ahead of time (slow loading time) or b) compile them as needed (lag spikes).
The core issue for this was solved years ago and now most of the pipeline states can be added to the command buffers ("dynamic states"). This solves the permutation explosion. But at the same time it opens the door for issue 2: some states (blending in particular) can cause a state-based recompile (like ye olde OpenGL days) at runtime.
The only solution to the second problem is not to use the dynamic states that trigger recompiling. That's basically only blending as far as I know. You can't even have dynamic blend state on all GPUs.
For maximum developer flexibility there's the shader object extension that allows mixing and matching shaders and pipeline states any way you want. This will cause state based recompiles at unpredictable times but it's an opt-in feature and easy to avoid if lag spikes are not wanted.
tl;dr: shader recompilation is easy to avoid in Vulkan but porting legacy engine code or art content may take you off the happy path.
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.
There's two tiers of precompiled though. Even if you can't download them precompiled, you can compile before the game launches so there are no stutters after.
Yes, many games do that too. Depending on how many shaders the game uses and how fast the user's CPU is an exhaustive pre-compile could take half an hour or more.
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.
I don't think this is as much of an issue as you are making it out to be. I have my Steam Deck on the main branch release which seems to exclude it from downloading precompiled shaders. When a game updates it has to compile the shaders first, but even on a big game this does not take an unreasonable amount of time. Less time than it takes for game updates to download at least.
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.
I remember Star Wars Jedi Survivor had a 5-6 minute shader pre-compile on my 5950X. I heard of people well into the 30 minute mark on lower core count machines. Battlefield 6 was a few minutes on my 9950X, higher again on lower core count CPUs.
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.
You're getting lucky with the games you're playing, then; there are absolutely PC games that have had 20-30 minute long shader compilation times _on high-end gaming hardware_. (I think some of Sony's ports were known for this; Googling tells me Borderlands 4, Stalker 2, and Starfield also had notably long shader times.) Typically those occur within the game's UI after launch but before the game starts playing, though, which makes me wonder if Valve might still be caching a non-GPU-specific intermediate of the DX12 to Vulkan conversion, and _that's_ what Linux Steam clients are compiling pre-launch and/or sharing with other clients. That's pure speculation on my part though, as I haven't played any of the worst-case-scenario games on my Deck, nor have I done anything that would cause the shader downloading to not operate.
So is this why on my laptop when I start a game after an update it starts "compiling vulkan shaders" for a few minutes? I've never understood what that was actually for but it takes 100% CPU on all cores so it's clearly doing something
Can't precompile for all the combinations of hardware, driver version, operating systems, etc... It's not really a vulkan specific problem and it's hard to solve. (for desktops anyways)
Honestly, this is either a game developer skill issue or laziness issue, not Vulkan's fault. Most big game developers have been notoriously negligent at any form of technical optimization in recent years.
Exciting! VulkanMod gives such drastic performance improvements, but it isn't compatible with most other mods. It'll be great to be using Vulkan with a full modpack in the future
As far as I remember the original plan was to only maintain both in a transitional phase, with the aim of fully replacing the Java edition. A simple plan: bring Bedrock to feature parity with Java, add a modding API that satisfies 95% of use cases, then force everyone onto Bedrock. The feature parity is mostly there, but modding in Bedrock seems to have become a non-goal, and Bedrock has so many bugs that if your platform offers the choice between both Java is still preferred even if you don't care about modding.
> As far as I remember the original plan was to only maintain both in a transitional phase
Is there a source for this? I don't remember any language to suggest Java Edition would eventually be replaced when they announced Windows 10 Edition. They've always indicated that they intend to keep maintaining the Java Edition, with parity in the core game. The messaging here has never changed, as far as I'm aware.
I'm not sure there are any direct quotes to that effect. But for four years the name of Bedrock Edition was simply "Minecraft" or "Minecraft for Windows", with the previous Minecraft becoming "Minecraft: Java Edition".
That's still the official name of bedrock, but it was never meant to establish a hierarchy or a plan for ending Java, they always seemed very careful in their words to avoid making it sound like it does.
If anything, they might have just done the rename simply for standardization over 9 different app stores with different requirements, branding requirements, and length limits before truncation occurs.
Ironically, it was originally built to support Android phones.
Pocket Edition was a stripped down version of the game to support the xperia play, so it was built for optimization from the start. Later it got support for broader Android devices and iOS, while Mojang outsourced console development to 4J studios. Eventually, they decided to beef up Pocket Edition to be mostly feature complete with Java, renamed it Bedrock, and made it the de facto standard for all devices, sunsetting 4J's port.
Java is for the modding user-base. If they would kill that, there is a good chance that the whole Youtube/Twitch creator ecosystem around the game dies, and with that it's popularity.
Bedrock is more performant and more portable across platforms (e.g. on consoles where you couldn't mod anyways).
It won't die. Its not a problem to skip auth checking if at some point MS tries to use kill switch (hopefully EU would make that fully legal in EU if that's not provided by the company).
As for feature parity, there are mods backporting modern features back to 1.7.10.
Java is also portable to all the consoles, its just Microsoft did use that as an argument to try to kill the Java Edition. Nobody prevented Microsoft from adding bedrock like modding to Java Edition.
The only thing that needs to happen is the one single stable mod API for Minecraft Java Edition. The incompatibility between Forge, NeoForge, Fabric, etc. is terrible, but from what I know about some of the folks involved this won't happen as they cannot constructively discuss the matters.
Wrong kind of death. Taking mods away after a decade and a half of the game being modded inside out would massively reduce the creative scope of the game for players. It would become "boring" and die out
They wanted everything on bedrock but they can’t do it, and losing the Java modding ecosystem would literally kill the game, which remains popular because of all the YouTube content, 90% of which is Java (even unmodded).
Much of the cashflow is from kids watching a YouTuber doing something in Java Minecraft and attempting it themselves in bedrock, which is why feature parity is the only thing they’re really working on anymore.
(Not saying you are but) I think people here are overstating modding and understating Bedrock's inferiority for content creation. The bugs, the differing technical surface and redstone logic, the basic missing key technical features from Java, like the F3 menu. Yes modding is a huge factor, but even if they released an amazing Bedrock modding API 3 years ago, Java would still be dominant in the content creation community and therefore still be the lifeblood of the game.
Bedrock is aimed at kids and they've never made any real effort to supplant Java with it. It's just a very effective way of hitting different target markets
Most mods don't even touch the rendering system, they just supply models in json format. If you do need custom rendering, Minecraft has the Blaze3D api, and that should be mostly unchanged. There are relatively few mods like Sodium and Iris that make extensive use of direct opengl calls.
it would be cool to use cosmickrisp instead at some point... in fact i saw someone run minecraft on macos using cosmickrisp -> zink to have modern opengl features that macos does not have
Java is the original version from Mojang/Notch. There’s always been enough of a community that killing it off to move away from Java would break so many extensions and servers would see an active revolt.
There is the non-Java version (Bedrock), but that’s not nearly as extensible.
It doesn’t really. Server side mods don’t touch rendering code at all, and most client side mods also don’t come anywhere near it. I last did Minecraft mod development some 7 years ago but even then you would basically never reach into the raw drawing calls unless you were implementing shaders or something.
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.
There's a whole community that plays on private servers and uses extensions for stuff like access control, new game mechanics (which doesn't mean new shaders but new behaviors in game) etc.
The native windows version is not moddable as described above. And probably will never be because MS wants you to rent "servers" from them.
So most "serious" minecraft players ignore bedrock.
Not a Java implementation, but the original game was written in Java. Later, Microsoft bought Minecraft and rewrote it (Bedrock edition) which runs on Xbox, tablets, etc. But, the community writes mods in Java.
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 is an open-source launcher to run Bedrock on Mac and Linux, and it runs well. Bedrock, however, still isn't as popular because servers and mods are more of an afterthought, so not a lot of effort has been put into making it developer-friendly.
As I recall the C++ reimplementation of Minecraft predates the Microsoft sale. Unless they did a complete rewrite I don't know about, Bedrock is distantly based on the old mobile/console version of Minecraft.
Minecraft Pocket Edition for Xperia Play
-> Minecraft: Pocket Edition
-> [Minecraft: Windows 10 Edition, Minecraft: Gear VR Edition,
Minecraft: Apple TV Edition, Minecraft: Fire TV Edition,
Minecraft: Pocket Edition]
-> Minecraft
(It is colloquially "Minecraft: Bedrock Edition" when Mojang is
distinguishing it from other versions. Note also that despite all
being named "Minecraft", different platforms are separate
licenses, but the Windows 10/11 license is bundled with Java Edition)
RubyDung
-> Cave Game
-> Minecraft: Order of the Stone
-> Minecraft
-> Minecraft: Java Edition
Minecraft: Xbox 360 Edition
-> [Minecraft: Xbox One Edition, Minecraft: PlayStation 3 Edition,
Minecraft: PlayStation 4 Edition, Minecraft: PlayStation Vita Edition,
Minecraft: Wii U Edition, Minecraft: Nintendo Switch Edition]
(This was the 4J Studios version, now deprecated as some platforms
are unsupported and on some platforms it is superseded by Bedrock.
It is sometimes referred to as "Console Edition" but this was
never official.)
Microsoft seems to be doing anything they can to get rid of Minecraft Java users having bought a Mojang license in the past. Either they are conspiring against their users, or they just don't care.
The dubious Mojang account migration. Their lack of support for kids who got their accounts phished recently. Migrating to Vulkan breaking old hardware.
Sad story, but it was to be expected MS bought Mojang.
I'm not super worried that this transition is cutting off hardware too soon.
- Vulkan requirement raises the baseline to 2016-2017 hardware. 2017 was 9 years ago.
- They're not cutting off OpenGL right away, according to the announcement they will release 26.1 as OpenGL-only, and then at least one more full release where you can choose between the two options. Based on their usual schedule it will probably be at least a year from now before they cut off OpenGL support, if not longer.
- All previous versions of the game are still available to play, including the oldest versions that run on Java 6, x86-32, OpenGL 1.2, Debian 5, Windows XP. Can still do multiplayer sessions on versions released in mid 2010.
- The community can fill in the gaps in multiple ways. Translation layers are available to connect to newer servers with older clients (ViaVersion), as well as with Bedrock clients (GeyserMC). Mods will almost certainly be released to reimplement the rendering engine in OpenGL or GLES. Renewed interest may mean OpenGL 2.0 compatibility mods could come back. Also, Mojang recently liberated Minecraft from variable name obfuscation, so modding will be easier than ever before.
- As a last resort, software rendering for Vulkan has gotten relatively mature, though obviously this means single digit FPS in many scenarios
Java Edition has taken an extremely conservative path, practically nothing else in the gaming industry held on to legacy hardware this long.
> - The community can fill in the gaps in multiple ways. Translation layers are available to connect to newer servers with older clients (ViaVersion), as well as with Bedrock clients (GeyserMC). Mods will almost certainly be released to reimplement the rendering engine in OpenGL or GLES. Renewed interest may mean OpenGL 2.0 compatibility mods could come back. Also, Mojang recently liberated Minecraft from variable name obfuscation, so modding will be easier than ever before.
And reimplementing the rendering engine for a different graphics API isn't even unprecedented, because there's a mod (VulkanMod) that reimplements the rendering engine for Vulkan already!
I hope this reduces the CPU overhead a bit on the main thread with some time. Quite a few games that ported from DX11 to 12 and openGL to Vulkan didn't just gain performance from the API swap it required taking advantage of the new higher parallel draw call capabilities. #
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.
I use Unigine Heaven to benchmark Linux systems. A colleague's friend has an epic spreadsheet of Heaven benchmarks across many configurations, and he submitted a few I've done. I ran it at home on my Linux desktop. For shits and giggles, I also downloaded the Windows version and ran it in Proton, and got a 30% performance boost! I suspect that a lot of that is due to the dxvk library that Proton uses, and the multithreading that it introduces translating D3D11 calls to Vulkan.
https://benchmark.unigine.com/heaven
https://github.com/doitsujin/dxvk
With a lot of games you can put DXVK DLLs in its folder and get better performance: https://github.com/doitsujin/dxvk/releases
There's a "newer" (almost ten years old) Unigine benchmark available called Superposition you should check out.
https://benchmark.unigine.com/superposition
I'm aware. I work in ewaste recycling, and most of the machines I come across are about 10 years old. I'm also a fan of JayzTwoCents. https://m.youtube.com/watch?v=ukb5tlT4IuQ
Maybe they can implement some of the calculations in GPU, as vulkan has feature to support that. This means voxel rendering could be accelerated
Does it actually use voxels? I thought it was just a low poly, "voxel like" art style.
The underlying world representation is chunky voxels, but they get triangulated into meshes for rendering. Unlike say, Teardown, which renders voxels directly.
Minecraft's non-world entities like players and enemies aren't voxels at any level though, those are directly authored as low poly meshes.
Not a bad choice... since Minecraft Java edition only supports desktops, they don't have to deal with the abysmal Vulkan drivers on mobile.
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)...
A company as large as Microsoft has resources to do a lot of things, but you’re not borrowing resources from the Office team to help on this project.
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.
TBH Mojang should have the resources to do that on his own, Minecraft is the best selling game of all times btw.
Minecraft is extremely mismanaged, the fact that the java version is still the ”main” version after all these years is just crazy
Why is it crazy? Any rewrite that would be as flexible wrt mods would be shaped similarly.
Java garbage collection gets out of control when cramming 100+ poorly optimized mods together. The bedrock edition is great in theory but the proper mod API never appeared. Regardless, people have accomplished some really impressive stuff with commands, but it is an exercise in pain.
The other issue with bedrock is it is far from feature parity with java. If these two things were hit then java could be reasonably retired. However we are decades too late in it being acceptable to introduce a breaking change to mod loading. So it's java forever.
Java garbage collection is what's allowing those 100+ poorly optimize mods to be functional at the same time in the first place.
Games with robust modding will almost always feature a garbage collected language which is what's primarily used for the modding.
Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
>Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Of course. Because they would fail loudly and would have to be fixed in order to run. Garbage collection is a crutch which lets broken things appear not broken.
Memory leaks very often don't fail loudly. Especially if they are slower leaks which don't immediately break the application.
A lot of the memory problems that you can see without a GC are hard to find and diagnose. Use after free, for example, is very often safe. It only crashes or causes problems sometimes. Same for double free. And they are hard to diagnose because the problems they do create are often observed at a distance. Use after free will silently corrupt some bit of memory somewhere else, what trips up on it might be completely unrelated.
It's the opposite of failing loudly.
> A lot of the memory problems that you can see without a GC are hard to find and diagnose
The nastiest leak I've ever seen in a C++ production system happened inside the allocator. We had a really hostile allocation pattern that forced the book-keeping structures inside the allocator to grow over time.
To be fair, I've seen something similar with the JVM, though it recovers. G1GC when it was first introduced would create these massive bookkeeping structures in order to run collections. We are talking about off JVM heap memory allocations up to 20% of the JVM heap allocation.
It's since gotten a lot better with JVM updates, so much so that it's not a problem in Java 21 and 25.
> Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Garbage collection does not solve memory leak problems. For example
- keeping a reference too long,
- much more subtle: having a reference to some object inside some closure
will also cause memory leaks in a garbage-collected language.
The proper solution is to consider what you name "poorly optimized mods" to be highly experimental (only those who are of very high quality can be treated differently).
> Garbage collection does not solve memory leak problems
It solves a class of memory leak problems which are much harder to address without the GC. Memory lifetimes.
It's true that you can still create an object that legitimately lives for the duration of the application, nothing solves that.
But what you can't do is allocate something on the heap and forget to free it. Or double free it. Or free it before the actual lifetime has finished.
Those are much trickier problems to solve which experienced C/C++ programmers trip over all the time. It's hard enough to have been the genesis of languages like Java and Rust.
I do wonder then how difficult it would be to mod games written in D
I don't think D has a "must use GC" mode, so probably easy to hit a footgun. It's the footguns that make things hard (IMO).
There is no "must use GC" mode, as far as I'm aware, but the footguns you describe only exist if the programmers opt-out of the GC. It's somewhat similar to using JNI/FFM in Java: it's possible to escape the safety of the VM. Though it's much easier to do so in D.
I always had trouble running bedrock as a household server. Specifically it would stop accepting connections and required daily restarts. Java was much more reliable.
You're right. Hytale is certainly shaped similarly in that regard.
Have you played Bedrock? It sucks.
I imagine it's far from the best-earning, though. It's a one-time purchase.
Skins, media packs, servers, hosted realms, upsales through all consoles, multiple copies for multiplayer with/between your kids… also a mass revolving shit tumbler of account stuff on the backend that invalidated lots of old accounts…
I bought during the beta for a lifetime of goodies, had to buy it again after the buyout, then again after an update to MS accounts wasn’t acted on, and then for the Switch. I’ve bought Minecraft 4 times, with another on the horizon if it keeps popular.
all of that except realms is bedrock edition, not the java one. I'm honestly pleasantly surprised they haven't killed the java version
That was probably their intention, but Bedrock has proven to be full of papercut sized bugs, and maintaining 1:1 behaviour with Java has also proven really difficult. Redstone is notably different/broken with the exception of trivial circuits.
Until it's possible to convert your world to Bedrock and not have anything in your 'finished' world break, except maybe some giant Redstone machine or one or two known annoyanced, I doubt they'd do it. Mojang presumably still has some autonomy within Microsoft so long as the money keeps coming in, and Mojang presumably knows that pushing this too early is a bad idea. But Microsoft being Microslop, who knows, maybe they'll just do it anyway.
I don't think 1:1 behaviour with Java was ever the intent. Redstone works differently due to a combination of different design choices, like not breaking in water (although I can imagine that being an accessibility thing for console players) and less technical debt, making things like movable tile entities possible.
I don't know what you mean by media packs, but the server software is free, and I believe all of the skins and maps released by Mojang itself on Bedrock's marketplace are also free. It's the third-party stuff that costs money, although I assume Mojang takes their cut.
They do have a bunch of add-ons now with Realms notably, but I wonder if this revenue goes to Mojang or to another Microsoft branch for tax reasons. To say nothing of derived media, plushies, Legos etc.
Fair, I completely forgot about Realms. I didn't know you could buy addons for them, though.
My kids have minecraft caps, tshirts, pants, pajamas, hoodies, lego, pencils, toys and probably other 100 things I do not remember right now
So no. It is not one time purchase.
You don't buy in-game money like GTA5, sure.
Then again, you'll never see a group of pre-schoolers wearing GTA5 hoodies and hats and backpacks, and you can't watch the GTA film in cinemas.
You need subscription for multiplayer
I don't think that's right. A Realms sub gives you a private server to play on but you don't need that. You can host your own for free.
On Xbox
This is an annoying and recent change; you used to be able to do local LAN multiplayer (even cross device!) before they changed something entirely.
At least split screen still works for free.
Nah, only if you're not willing to self host.
I run a 6 person server on an Intel NUC, without major issue.
They use bgfx for bedrock edition.
https://github.com/bkaradzic/bgfx
https://www.minecraft.net/en-us/attribution
An aside, but out of five links for Java edition one is 404 and the next one is an HTTP-only site seemingly not updated since 2009.
Funny to contrast with Bedrock edition, for which they paid for FMOD Studio to cover the audio features of those two (and more).
This is such a gold mine project! thanks for sharing it.
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
https://github.com/raysan5/raylib/discussions/1699
> Why not just use bgfx with the language bindings instead.
For me the biggest obstacle would be the weird build system the project insists on using.
Honestly pick between Vulkan and DX12 is very superficial.
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.
The reason you use DX12 in a new project is so that you can get good linux support.
I'm making a joke, but it's also true.
How good does Wine support DX12?
Support for DX12 under Proton in linux is incredibly good. Some games actually run faster under DX12 in Proton than the native versions do.
I don't think it's faster than a windows game running Vulkan, though, is it? Like, if you benchmarked a game that has native DX12 and Vulkan modes (such as Wolfenstein: The New Colossus, I believe), it will probably have higher FPS in Vulkan mode, right?
Well our game runs faster in DX12 under Proton than Vulkan under Proton.
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.
DXVK does not need wine.
Never mind, DXVK isn't for DX12.
it translates the calls to vulkan.
but why would you pick the worst API?
On mobile 3rd party launchers use ANGLE to use EGL or Metal drivers.
Damn, this will break Minecraft on my original machine, an Acer C720 Chromebook modded to run Linux. The Intel HD4400 iGPU doesn’t support Vulcan!
I always appreciated that MC would run on virtually any hardware, especially as a kid without access to anything nice.
> Once this happens, players will be able to switch between OpenGL rendering and Vulkan rendering
I think this means you'll be able to continue using Minecraft with OpenGL.
In the following paragraph:
> Once we’re happy with the performance and stability of Vulkan across devices we will remove the OpenGL implementation.
So not for long.
It's pretty interesting that OpenGL achieved its stated goal and is the graphics API with the highest degree of compatibility across many devices.
Vulkan more or less also has that goal, but for then-current hardware 24 years later (2016). In this case (Intel HD Graphics 4400, Haswell?), there is unofficial support on Linux that can be enabled with some hacks, and it may or may not work. Similar support for my previous (desktop) AMD GPU generally worked fine. The situation for Haswell seems more iffy, though.
At least Java lets you run older versions so you can just play 1.7.10 forever as Notch intended.
Notch already sold Minecraft to Microsoft before 1.7.10 was released.
It depends what features they use but under Mesa that chip does have some Vulkan support.
it looks like "in hardware" it has vulkan 1.0 support, but looking at https://mesamatrix.net the hasvk driver (which i think is the haswell/gen 7 and 8 driver) seems to have some support for more recent extensions
and of course all the previous minecraft versions will continue working on opengl :p
I'm glad someone else is still using a C720. I keep mine in a case with some SDR gear. One of my favorite computers i've owned.
It was a great machine. It was my daily driver until a few years ago. I ran xubuntu on it with the Mr Chromebook firmware for a loooong time until my most commonly used websites became so heavy browsing was impossible.
I got mine first year of college because my 5ish year old 15" mbp was just too much of a boat anchor. I got a launch model with the celeron, 4gb of ram, and no touch screen so the battery life would last all day and then some.
I installed Chrouton which let you switch between chromeOS and a full ubuntu chroot, which was the best of both worlds as you could do the optimized browsing on ChromeOS and development tasks on the chroot.
After it fell out of ChromeOS favor, I just installed arch on it and called it a day. It's my go-to conference laptop because it's still so conveniently small, light, and 12 years on the battery still gets 6 hours.
Time for an upgrade buddy. I need my 32 chunk render distance when i play java, personally. A 10+ year old chromebook would not be cutting it - but it doesn't take much either if your simulation distance is low.
Who would have thought that Microsoft would end up getting cosier with Khronos standards than Apple. This is after they adopted SPIR-V both as a target in their shader compiler and as an ingest format in DirectX, smoothing over interop with Vulkan in both directions.
Microsoft has already been there before as well, they are adopting SPIR-V only to cut down their fork, and because Google already did part of the work for them.
Apple apparently got very pissed on how Khronos took care of OpenCL.
Then Sony and Nintendo couldn't care less about Khronos, people keep forgetting about game consoles when discussing the portability of Khronos APIs, or ignoring the fact that in reality they aren't really that portable due to the extension spaghetti.
> Nintendo couldn't care less about Khronos
I wouldn't be so sure about Nintendo. From time to time you see them pop up as contributors for some extensions.
https://github.com/search?q=repo%3AKhronosGroup%2FVulkan-Doc...
Indeed, however OpenGL and Vulkan are mostly for porting purposes, if you want the real device goodies, it is either NVN, or extensions that are only available on Nintendo devices, hardly a difference.
Why not move comments to source? https://news.ycombinator.com/item?id=47061529
Just goes to show timing of your post matters more than the content.
Or that it depends on luck.
or potentially the account posting it
I hope Vibrant Visuals comes to Minecraft Java Edition quickly, it's a shame you need mods to have shaders on Java.
> it's a shame you need mods to have shaders on Java
You don't. Ever since 1.17 you have been able to build GL shaders directly into resource packs. Resource packs don't require any complex loaders and don't pose a malware risk. To install them you can either drag-and-drop them as .zips directly into the resource pack menu, or a server/world can be configured to prompt the installation of a resource pack. These resource pack shaders are not quite as flexible as Aperture, Iris, or Optifine shaders, but they are fairly close in functionality.
I'm curious if they will carry over this functionality for Vulkan shaders embedded into resource packs. I suspect they may not, which is understandable given how it can be used to break the game's functionality much worse than an ordinary resource pack can (not full RCE, though)
> Ever since 1.17 you have been able to build GL shaders directly into resource packs
This sounds very cool, I never knew this. Could you give me an example of such pack?
Here are a bunch of examples: https://github.com/McTsts/mc-core-shaders
This one is particularly interesting because it integrates block data in the rendered world along with some server-side augmented data to render a minimap in a vanilla client: https://github.com/JNNGL/VanillaMinimaps
It seems kind of odd to play Java edition without mods at all. Wouldn't you have a simpler time on Bedrock?
Well... people do call it Bugrock for a reason.
Also redstone is different, there's no F3 menu, generally far less vanilla customisability, far more micro-transaction prompting, far fewer commands and I'm sure 20 other things that someone who has actually played Bedrock recently could name
This thread is quite weird to me. People are massively overstating how important modding is and understating the strength of vanilla Java. Minecraft is not Skyrim
Speedrunning, anarchy servers, parkour, technical farming, server economy destruction videos and other primarily vanilla Java content forms are as popular as ever or more. Alongside the newer content creators, Hermitcraft is still growing somehow, as is Etho. Besides anarchy a little bit, none of this is reliant on modding
There are significant updates every year and many people, including me, install them every time they come out and play them in vanilla.
Speedrunning is very much modded - ranked (the big content) is just flat out modded (not just the match setup, there are game tweaks too (guaranteed blaze drops after 20 or so iirc, guaranteed dragon perch in ≤3 mins)), and even RSG/SSG/AA/etc have a long list of allowed mods (much quicker seed rerolling, timer, perf improvement mods, etc). Many(/most/all? idk) Many (/most/all? idk) hermits use mods (esp. freecam, replaymod for creating timelapses / pretty camera perspectives). Never mind shaders sprinkled in a portion of everything.
These are minor tweaks. You could remove these and the speedrunning community/HC would lose little. A second account in spectator mode is a slightly less convenient version of freecam and the speedrunning community is kidding themselves in the first place allowing any tweaks to RNG whatsoever. They could ban that tomorrow and there'd be some grumbling but nothing would change viewership-wise
Minor tweaks are still a mod. Gameplay overhaul modpacks that turn the game into Factorio are definitely the a small minority of the playerbase, but anyone who knows better plays with at least some sort of client-side performance mod (Optifine, Lithium, etc), and that's been true since before 1.0.
Etho's dedication to keeping a purely vanilla singleplayer world is a unique feat. If you want to use Hermitcraft as an example of the median SMP, their modlist is actually quite large: https://github.com/henkelmax/hermitcraft-server
Minecraft simply has a lot of areas for improvement that haven't been touched by Mojang for one reason or another, and a big reason why people stick with Java is because the community has built an ecosystem to tweak the game to their liking.
I never said that modding isn't important, I said that it's not as important as people in this thread are making it out to be
The main actual speedrunning categories don't allow any RNG changes; but I doubt anyone doing RSG would have any interest whatsoever going back to the 20x-or-whatever slower seed rolling, that's just a completely utterly dumb waste of time doing literally nothing except clicking a button every 5 seconds (effectively changing the category from "who can play the game the best" to much more like "who has the most beast of a machine to run as many minecraft instances in parallel to more quickly roll a good seed"). Viewership would definitely go down from there being less actual gameplay.
Ranked is intended to be a fun competitive thing; waiting 10 minutes for a dragon perch doing nothing is Not Fun; waiting forever at a spawner is Not Fun; simple as that, people wouldn't play it if it wasn't fun. (oh, also, I believe Ranked also just generally includes making mob drops consistent for the same seed (and consistent portal locations, and probably other things), without which the whole entire concept of competitively playing the same seed would not work whatsoever, devolving to just who got the better RNG, distinctly Not Fun; also the ability to review a replay of your game afterwards for learning). Viewership and player counts would go down because you'd just be looking at very slow gambling instead of something actually meaningfully-skill-based.
A second account might work for freecam (though it adds more editing work, aka makes you not want to actually use it much), but making pretty timelapses is not feasible that way. Granted, you could still live without it, but the quality of content would undoubtedly go down. The little things go a long, long, long way.
To be clear I do kinda agree with the general idea that modding isn't that important to Minecraft Java; but it's still very important at least indirectly - were there not as large of a modding scene, I'd imagine many more content creators would've long ran out of content to make on it (or at least unique ways to do things), and the technical research/farms/whatever would be hampered by less available tooling.
(for what it's worth, last I played minecraft, like 1-2 years ago, I did so lightly-modded - Do A Barrel Roll for much more fun elytra; lithium; Distant Horizons; Hydrophobic Elytra to fix a stupid extremely-annoying elytra bug (might be fixed now?), BetterF3 (kinda superceded by the more recent F3 overhaul now I suppose?))
I wasn’t aware Java had Vulkan bindings. So this is JNI I’m guessing?
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.
To elaborate on the other comment about the Foreign Function & Memory API: JNI is effectively dead/deprecated, and has been replaced by the aforementioned API. It is orders of magnitude more developer friendly to use. It handles memory much more cleanly. It's way easier to create bindings to talk to foreign functions (e.g. Vulkan).
Probably the most underappreciated great feature in recent Java releases.
It will be a while before JNI itself is dead, because far too much stuff still relies on it. The unsafe helpers in the Java standard library will die first because they are fundamentally incompatible with Valhalla, but it's likely the simple cases will last a while as there are vast swaths of glue code that needs to be rewritten.
IIRC Minecraft is still using entirely JNI and no FFM yet. That will probably start to change in the near future, though. Some modders have already been replacing their own natives with FFM versions.
Hopefully it would use the Foreign Function and Memory API instead of JNI.
I'm pretty sure Mojang will just use the Vulkan bindings provided by LWJGL, considering that Minecraft uses LWJGL
This is great news. I was super disappointed when Rainbow Six Siege dropped the Vulkan version of their game. They cited the support burden as the reason they dropped it, as nearly every game in the studio defaulted to DX11/12. For at least two years after that they received non-stop complaints of frame stutters on DX12. I do not know if the situation has gotten much better since then.
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.
We have one for Bedrock fwiw. JavaScript based (via QuickJS).
https://learn.microsoft.com/en-us/minecraft/creator/scriptap...
That's the least of R6's problems!
For modding, Minecraft Java has data packs. You can't do everything you can do with mods with that though.
I hope they have a solution to the notorious Vulkan shader compilation lag spikes.
I don't think Minecraft's renderer will be PSO-heavy enough to have stuttering issues. It's not a state-of-the-art compute-driven renderer that supports artist-driven workflows with custom materials and shaders... it's just a voxel renderer with very primitive lighting.
I wouldn't trust them to not implement the next version of Minecraft in UE5 with nanite and lumen
And by voxels you mean triangles
Are you the real direwolf20?
> notorious Vulkan shader compilation lag spikes.
Vulkan gives all the tools to avoid any "lag spikes" from shader compiling. In fact, causing them is much more difficult than OpenGL where they could happen in surprising places (and only on certain hardware).
The issue is two fold: 1. Some engines produce a lot of shader permutations. Some AAA titles can have 60000 different shaders compiled. 2. Some GPU rasterizer states (such as color blending) are implemented as shader epilogues.
In Vulkan 1.0 almost all of the pipeline state had to be pre-baked into a pipeline state object compiled ahead of time. This lead to a "shader permutation explosion" where different states need different pipelines.
This requires the game engine to either a) compile all the pipeline combinations ahead of time (slow loading time) or b) compile them as needed (lag spikes).
The core issue for this was solved years ago and now most of the pipeline states can be added to the command buffers ("dynamic states"). This solves the permutation explosion. But at the same time it opens the door for issue 2: some states (blending in particular) can cause a state-based recompile (like ye olde OpenGL days) at runtime.
The only solution to the second problem is not to use the dynamic states that trigger recompiling. That's basically only blending as far as I know. You can't even have dynamic blend state on all GPUs.
For maximum developer flexibility there's the shader object extension that allows mixing and matching shaders and pipeline states any way you want. This will cause state based recompiles at unpredictable times but it's an opt-in feature and easy to avoid if lag spikes are not wanted.
tl;dr: shader recompilation is easy to avoid in Vulkan but porting legacy engine code or art content may take you off the happy path.
I’m not even a neophyte here but why don’t precompiled shaders solve that?
Depends what you're precompiling.
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.
There's two tiers of precompiled though. Even if you can't download them precompiled, you can compile before the game launches so there are no stutters after.
Yes, many games do that too. Depending on how many shaders the game uses and how fast the user's CPU is an exhaustive pre-compile could take half an hour or more.
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.
I don't think this is as much of an issue as you are making it out to be. I have my Steam Deck on the main branch release which seems to exclude it from downloading precompiled shaders. When a game updates it has to compile the shaders first, but even on a big game this does not take an unreasonable amount of time. Less time than it takes for game updates to download at least.
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.
I remember Star Wars Jedi Survivor had a 5-6 minute shader pre-compile on my 5950X. I heard of people well into the 30 minute mark on lower core count machines. Battlefield 6 was a few minutes on my 9950X, higher again on lower core count CPUs.
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.
You're getting lucky with the games you're playing, then; there are absolutely PC games that have had 20-30 minute long shader compilation times _on high-end gaming hardware_. (I think some of Sony's ports were known for this; Googling tells me Borderlands 4, Stalker 2, and Starfield also had notably long shader times.) Typically those occur within the game's UI after launch but before the game starts playing, though, which makes me wonder if Valve might still be caching a non-GPU-specific intermediate of the DX12 to Vulkan conversion, and _that's_ what Linux Steam clients are compiling pre-launch and/or sharing with other clients. That's pure speculation on my part though, as I haven't played any of the worst-case-scenario games on my Deck, nor have I done anything that would cause the shader downloading to not operate.
So is this why on my laptop when I start a game after an update it starts "compiling vulkan shaders" for a few minutes? I've never understood what that was actually for but it takes 100% CPU on all cores so it's clearly doing something
It kinda does. Kinda. Steam constantly downloads precompiled shaders for your games. Especially on Linux.
Can't precompile for all the combinations of hardware, driver version, operating systems, etc... It's not really a vulkan specific problem and it's hard to solve. (for desktops anyways)
Honestly, this is either a game developer skill issue or laziness issue, not Vulkan's fault. Most big game developers have been notoriously negligent at any form of technical optimization in recent years.
Exciting! VulkanMod gives such drastic performance improvements, but it isn't compatible with most other mods. It'll be great to be using Vulkan with a full modpack in the future
Why are they even maintaining two versions of the same game?
As far as I remember the original plan was to only maintain both in a transitional phase, with the aim of fully replacing the Java edition. A simple plan: bring Bedrock to feature parity with Java, add a modding API that satisfies 95% of use cases, then force everyone onto Bedrock. The feature parity is mostly there, but modding in Bedrock seems to have become a non-goal, and Bedrock has so many bugs that if your platform offers the choice between both Java is still preferred even if you don't care about modding.
> As far as I remember the original plan was to only maintain both in a transitional phase
Is there a source for this? I don't remember any language to suggest Java Edition would eventually be replaced when they announced Windows 10 Edition. They've always indicated that they intend to keep maintaining the Java Edition, with parity in the core game. The messaging here has never changed, as far as I'm aware.
I'm not sure there are any direct quotes to that effect. But for four years the name of Bedrock Edition was simply "Minecraft" or "Minecraft for Windows", with the previous Minecraft becoming "Minecraft: Java Edition".
https://www.minecraft.net/en-us/article/all-news-e3
https://minecraft.wiki/w/Bedrock_Edition#Nomenclature
That's still the official name of bedrock, but it was never meant to establish a hierarchy or a plan for ending Java, they always seemed very careful in their words to avoid making it sound like it does.
If anything, they might have just done the rename simply for standardization over 9 different app stores with different requirements, branding requirements, and length limits before truncation occurs.
Such a colossal waste..
I still don’t understand what problem Bedrock Edition solves. I guess it was for consoles that don’t support Java?
Ironically, it was originally built to support Android phones.
Pocket Edition was a stripped down version of the game to support the xperia play, so it was built for optimization from the start. Later it got support for broader Android devices and iOS, while Mojang outsourced console development to 4J studios. Eventually, they decided to beef up Pocket Edition to be mostly feature complete with Java, renamed it Bedrock, and made it the de facto standard for all devices, sunsetting 4J's port.
Yes, and performance. Java edition is slow as hell in comparison, it just doesn't matter on PCs too much unless you really mod it.
Put more simply, a large proportion of the existing playerbase, including most large content creators, despises Bedrock.
Java is for the modding user-base. If they would kill that, there is a good chance that the whole Youtube/Twitch creator ecosystem around the game dies, and with that it's popularity.
Bedrock is more performant and more portable across platforms (e.g. on consoles where you couldn't mod anyways).
It won't die. Its not a problem to skip auth checking if at some point MS tries to use kill switch (hopefully EU would make that fully legal in EU if that's not provided by the company).
As for feature parity, there are mods backporting modern features back to 1.7.10.
Java is also portable to all the consoles, its just Microsoft did use that as an argument to try to kill the Java Edition. Nobody prevented Microsoft from adding bedrock like modding to Java Edition.
The only thing that needs to happen is the one single stable mod API for Minecraft Java Edition. The incompatibility between Forge, NeoForge, Fabric, etc. is terrible, but from what I know about some of the folks involved this won't happen as they cannot constructively discuss the matters.
Wrong kind of death. Taking mods away after a decade and a half of the game being modded inside out would massively reduce the creative scope of the game for players. It would become "boring" and die out
They wanted everything on bedrock but they can’t do it, and losing the Java modding ecosystem would literally kill the game, which remains popular because of all the YouTube content, 90% of which is Java (even unmodded).
Much of the cashflow is from kids watching a YouTuber doing something in Java Minecraft and attempting it themselves in bedrock, which is why feature parity is the only thing they’re really working on anymore.
(Not saying you are but) I think people here are overstating modding and understating Bedrock's inferiority for content creation. The bugs, the differing technical surface and redstone logic, the basic missing key technical features from Java, like the F3 menu. Yes modding is a huge factor, but even if they released an amazing Bedrock modding API 3 years ago, Java would still be dominant in the content creation community and therefore still be the lifeblood of the game.
Bedrock is aimed at kids and they've never made any real effort to supplant Java with it. It's just a very effective way of hitting different target markets
That's the underlying reality - they wanted Bedrock to unify all the non-PC platforms (phones, consoles, etc) and they succeeded on that.
They have no need to supplant Java, nor any desire to (and all their marketing materials and screenshots are usually Java anyway).
Because they aren't the same, Bedrock is more limited in modding capabilities, and the Java community doesn't care about it.
Microsoft logically wants to keep sales from both.
Discontinuing Java would make a lot of players stop playing (including me).
Maybe smooth shading will finally work on water in Java edition!
I bet they will lose most of the mods, as I don't see many wanting to learn Vulkan only to port their mods.
They better make use of Zink/Angle or similar approaches.
Most mods don't even touch the rendering system, they just supply models in json format. If you do need custom rendering, Minecraft has the Blaze3D api, and that should be mostly unchanged. There are relatively few mods like Sodium and Iris that make extensive use of direct opengl calls.
I wasn't aware of Blaze3D, thanks.
I feel like paid shaders will be ported fine haha ;)
I love to play minecraft
l love to play minecraft
lol bye
lol
> For the macOS side of things, they'll use a translation layer since Apple don't support Vulkan directly (they made their own API with Metal)
Where does it say that? Why not use MoltenVK?
I think MoltenVK probably is the translation layer they're using.
it would be cool to use cosmickrisp instead at some point... in fact i saw someone run minecraft on macos using cosmickrisp -> zink to have modern opengl features that macos does not have
MoltenVK was replaced by KosmicKrisp
[flagged]
I'm frankly shocked microsoft has a java implementation. I thought they were the type of organization to pretend it didn't exist!
Java is the original version from Mojang/Notch. There’s always been enough of a community that killing it off to move away from Java would break so many extensions and servers would see an active revolt.
There is the non-Java version (Bedrock), but that’s not nearly as extensible.
Switching to vulkan breaks all the extensions too
It doesn’t really. Server side mods don’t touch rendering code at all, and most client side mods also don’t come anywhere near it. I last did Minecraft mod development some 7 years ago but even then you would basically never reach into the raw drawing calls unless you were implementing shaders or something.
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.
No, it only breaks the eye candy extensions.
There's a whole community that plays on private servers and uses extensions for stuff like access control, new game mechanics (which doesn't mean new shaders but new behaviors in game) etc.
The native windows version is not moddable as described above. And probably will never be because MS wants you to rent "servers" from them.
So most "serious" minecraft players ignore bedrock.
Ah, I had misread "minecraft" as "microsoft". I wasn't aware minecraft java was a thing. Crazy they have their own java implementation!
Not a Java implementation, but the original game was written in Java. Later, Microsoft bought Minecraft and rewrote it (Bedrock edition) which runs on Xbox, tablets, etc. But, the community writes mods in Java.
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.
There is also this:
> 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 is an open-source launcher to run Bedrock on Mac and Linux, and it runs well. Bedrock, however, still isn't as popular because servers and mods are more of an afterthought, so not a lot of effort has been put into making it developer-friendly.
As I recall the C++ reimplementation of Minecraft predates the Microsoft sale. Unless they did a complete rewrite I don't know about, Bedrock is distantly based on the old mobile/console version of Minecraft.
[dead]
It’s the Java version of the game, not a game version of Java.
There’s a native version called bedrock
> It’s the Java version of the game, not a game version of Java.
This would be termed "Java Minecraft", not "Minecraft Java"
No, the game's Java version's official title post-Microsoft acquisition of Mojang is Minecraft: Java Edition.
They have renamed both product lines, Bedrock edition many times.
Specifically:
You appear to be the only one confused
While you meant Minecraft here, to shock you further, please enjoy this:
https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
They also currently release their own build of OpenJDK.
https://www.microsoft.com/openjdk
Microsoft is open about how much Java they use
https://cdn.graph.office.net/prod/media/java/how-microsoft-a...
Microsoft seems to be doing anything they can to get rid of Minecraft Java users having bought a Mojang license in the past. Either they are conspiring against their users, or they just don't care.
The dubious Mojang account migration. Their lack of support for kids who got their accounts phished recently. Migrating to Vulkan breaking old hardware.
Sad story, but it was to be expected MS bought Mojang.
I'm not super worried that this transition is cutting off hardware too soon.
- Vulkan requirement raises the baseline to 2016-2017 hardware. 2017 was 9 years ago.
- They're not cutting off OpenGL right away, according to the announcement they will release 26.1 as OpenGL-only, and then at least one more full release where you can choose between the two options. Based on their usual schedule it will probably be at least a year from now before they cut off OpenGL support, if not longer.
- All previous versions of the game are still available to play, including the oldest versions that run on Java 6, x86-32, OpenGL 1.2, Debian 5, Windows XP. Can still do multiplayer sessions on versions released in mid 2010.
- The community can fill in the gaps in multiple ways. Translation layers are available to connect to newer servers with older clients (ViaVersion), as well as with Bedrock clients (GeyserMC). Mods will almost certainly be released to reimplement the rendering engine in OpenGL or GLES. Renewed interest may mean OpenGL 2.0 compatibility mods could come back. Also, Mojang recently liberated Minecraft from variable name obfuscation, so modding will be easier than ever before.
- As a last resort, software rendering for Vulkan has gotten relatively mature, though obviously this means single digit FPS in many scenarios
Java Edition has taken an extremely conservative path, practically nothing else in the gaming industry held on to legacy hardware this long.
> - The community can fill in the gaps in multiple ways. Translation layers are available to connect to newer servers with older clients (ViaVersion), as well as with Bedrock clients (GeyserMC). Mods will almost certainly be released to reimplement the rendering engine in OpenGL or GLES. Renewed interest may mean OpenGL 2.0 compatibility mods could come back. Also, Mojang recently liberated Minecraft from variable name obfuscation, so modding will be easier than ever before.
And reimplementing the rendering engine for a different graphics API isn't even unprecedented, because there's a mod (VulkanMod) that reimplements the rendering engine for Vulkan already!