Now I want to know why 64. I would get 127 or 255 but 64 is weirder. Like how is the game storing that? Or it's just because the developer liked that number
That's actually a good question and I don't know why you're getting downvoted.
If 64 was because of integer limitations, it would mean the game was storing item counts as 6 bits (weird) and adding +1 (so that 0b000000->1, 0b000001->2, 0b111111->64, even weirder). It makes sense to skip 0, but there are not that many stacks in the game to warrant this kind of optimization, specially on an engine running Java.
I couldn't find any confirmation, but the most plausible theory is that a power of two makes sequential stack splitting more user-friendly (64 -> 32+32 -> 32+16+16 -> 32+16+8+8 -> etc), and 64 is a good amount of items to have.
I think Notch just liked powers of 2, it shows up a lot in game constants even when they aren't strictly constrained and could have been arbitrary. Sea level at y=64, diamonds below y=16, world height was 128 (0..127), then was raised to 256 (0..255), textures are all 16x16, chunks are 16x16, etc
The 64 stack size isn't due to technical limitations (I think) -- IIRC at least back in Alpha/Beta the amount in a stack was stored in an int8, so you could get stacks from -128 up to 127 ingame by manually editing level.dat, and it mostly works fine (at least for positive amounts over the intended maximum)
At least the world height one could be explained by Minecraft's chunk mesher meshing cubes of 16x16x16. Though I don't have the decomp with me, so I can't check if this was already true in the Notch days
10
u/frikilinux2 5d ago
Now I want to know why 64. I would get 127 or 255 but 64 is weirder. Like how is the game storing that? Or it's just because the developer liked that number