Live data from Hacker News

Minecraft Java raises recommended memory to 16GB ahead of Vulkan transition

videocardz.com

81–85 of 85 posts

Re: Minecraft Java raises recommended memory to 16GB ahead of Vulkan transition

#81
post #75
post #69

Earlier quoted context omitted.

1.3, not beta 1.3. Chunk data was traditionally the biggest part of Minecraft's memory use until they added a bunch more garbage.

Interesting they switched after a couple years! > Chunk data was traditionally the biggest part of Minecraft's memory use until they added a bunch more garbage. But that's only really because it is extremely light on assets that are typically large in other games. I'm a bit indifferent about this. Obviously they made a lot of decisions that aren't good for performance but it's a tradeoff. Notch was most productive wo…

Yes, Minecraft doesn't have a ton of assets and it does have a lot of block data, so they should have optimized the block data and not worried about the rest. Instead they pessimized the block data.

They even managed to pessimize the assets. They did this by, during startup, pre-converting every possible rendering state of every block in the game into a static 3D model made out of Java objects (Vertex, Face, etc). This wastes about a GB of RAM.

Before Minecraft 1.8, blocks were rendered by running block-specific code for each block to render it in the needed state. One function would append a ladder to a vertex buffer, another function would append a cube to a vertex buffer, another one for stairs, etc. Since the same code block would render any material variant and direction variant of stairs, this didn't use excessive memory.

I know that in 1.8, the biggest single waste of models was redstone dust, because it comes in 16 power levels and approximately 3^4 side connection states (connected, not connected, and connected up the side of a block, but not all combinations are possible) which is over 1000 unique models. Not sure if this is still the case.

Re: Minecraft Java raises recommended memory to 16GB ahead of Vulkan transition

#82
post #80

Earlier quoted context omitted.

The stuff they're rendering has to come from somewhere. They go hand in hand, the bigger the render area, the more game has to be simulated at once.

Not true. Render distance and simulation distance were decoupled years ago.

It's possible to simulate less than you can see, but it's pretty undesirable. The recommendations scale with this.

Re: Minecraft Java raises recommended memory to 16GB ahead of Vulkan transition

#83
post #3

Earlier quoted context omitted.

I have lots of problems with Microsoft but the Minecraft transition was handled very responsibly.

barely made it myself. Turns out the MS username namespace didn't allow all minecraft names. I repeatedly failed migration because it was trying to auto-port an illegal username. the error was of course entirely opaque.

The MS username space is completely unrelated to the Minecraft one. You have two usernames and the old ones haven’t been changed.

Re: Minecraft Java raises recommended memory to 16GB ahead of Vulkan transition

#84
post #81
post #75

Earlier quoted context omitted.

Interesting they switched after a couple years! > Chunk data was traditionally the biggest part of Minecraft's memory use until they added a bunch more garbage. But that's only really because it is extremely light on assets that are typically large in other games. I'm a bit indifferent about this. Obviously they made a lot of decisions that aren't good for performance but it's a tradeoff. Notch was most productive wo…

Yes, Minecraft doesn't have a ton of assets and it does have a lot of block data, so they should have optimized the block data and not worried about the rest. Instead they pessimized the block data. They even managed to pessimize the assets. They did this by, during startup, pre-converting every possible rendering state of every block in the game into a static 3D model made out of Java objects (Vertex, Face, etc). Th…

> Yes, Minecraft doesn't have a ton of assets and it does have a lot of block data, so they should have optimized the block data and not worried about the rest. Instead they pessimized the block data.

Inefficient but surely beneficial to modding.

> pre-converting every possible rendering state of every block in the game into a static 3D model made out of Java objects (Vertex, Face, etc). This wastes about a GB of RAM.

Alternatively, these are the game's assets, so it isn't a waste. Running the code to generate blocks all the time wouldn't be ideal so caching makes sense but I don't know why they wouldn't lazily populate it.

Re: Minecraft Java raises recommended memory to 16GB ahead of Vulkan transition

#85

I highly recommend using the open source Sodium and Lithium mods to improve performance. And I hope you're not still using OptiFine! https://github.com/CaffeineMC/sodium https://github.com/CaffeineMC/lithium

Hey, neat! Did they already ship Vulkan support?!
Post reply on HN