It's not about poor coding.
I would like to point something out. Modern graphics cards could process a large part of Minecraft in the card itself. Systems like PhysX attempt to do just that—CUDA, OpenCL etc. Consequently, this would increase VRAM usage.
Here's some things that could easily (relatively speaking) be offloaded to the graphics driver:
- Tick updates of blocks (think leaf blocks dying, lighting updates, etc.)
- Procedural generation
- Fluid updates
However, GPU processing in a shader language (GLSL, HLSL, SPIR-V) is much more difficult and bug prone than a high level language like Java. Thus, all of these things are performed on the CPU.
Although several games have implemented some of that in GPUs before, Minecraft didn't have the large, skilled resource pool that triple-A titles have.
Suppose Minecraft uses a 32-bit color scheme.
32 bits per color
4 colors per pixel (red, green, blue, alpha)
8 bits per byte
(32 bits * 4 colors per pixel) / 8 bits per byte = 128 / 8 = 16 bytes per pixel.
100MB / 16 bytes per pixel = 6,250,000 pixels
sqrt(6250000) = 2500x2500 image resource in GPU (uncompressed)
2500 pixels wide|tall / 16 pixels wide|tall = 156.25 tiles wide|tall (assuming 16x16 tile size)
156.25 tiles wide * 156.25 tiles tall = ~24,414 16x16 tiles.
In summary, you can store ~24,414, 16x16 tiles in an uncompressed, 32-bit, image resource in VRAM.
This exercise really helped me wrap my head around why Factorio had issues with it's sprite-sheets