I've been reading through the source because I'm interested in how Minecraft works from a programming point of view.

 

So far I've found Block.java and IBlockAccess.java, and they have methods such as "isAirBlock(x,y,z)" etc.

 

However I cannot find anywhere in the source where or how it keeps blocks in memory. For example, are the blocks kept in some kind of three dimensional array or list that is declared in "Chunk.java"?

 

The nearest I've been able to find is:

    /** List of ly/ff (BlockType) containing the already registered blocks. */
    public static final Block[] blocksList = new Block[4096];

 

However by the looks of it, that is just used for registering new block types.

public class Chunk
{

    /**
     * Used to store block IDs, block MSBs, Sky-light maps, Block-light maps, and metadata. Each entry corresponds to a
     * logical segment of 16x16x16 blocks, stacked vertically.
     */
    private ExtendedBlockStorage[] storageArrays;

i think the mcp team mush have derped, a chunk is 16x16x256

i think the mcp team mush have derped, a chunk is 16x16x256

 

A chunk is an array of ExtendedBlockStorage objects, each of which is 16x16x16.  So 16 of them.

(An ExtendedBlockStorage is a fancy class that stores blocks as two arrays: one for the least significant bits as a byte and one, complex data type that is effectively a byte with some other functions, for the most significant bits).

What draco said ^

 

+ if you look into world.setBlock methods, and follow it down into it's deepest level you will get to the extended block storage, that should give you a view of exactly how a block is set or get from the world

 

Also this blog may give insight into some of minecrafts internals:

http://greyminecraftcoder.blogspot.no/p/list-of-topics.html

Also some helpful insight from XCompWiz:

 

I made a constructor in Forge to allow for block arrays of short ids to work.  The indexing is different from the standard chunk block array, so note that.

 

The main thing is that it is normally a byte array.  Byte only accept values from -128 to 127.  This means if you try to put in a value that's larger it will cut off the "top" of it.

 

The constructor I wrote uses a short array for the block id and another array for the metadata.  The indexing for these is reverse the vanilla way.

Vanilla indexes the arrays such that the y coordinate is the "lowest order bits", which is why world generation only supports up to y127.  I put the y coordinate on the higher order bits, with x and z (which are fixed constants due to the size of a chunk) on the lower bits.

I don't remember which of x or z is the lowest order of bits, but it should be possible to check from the constructor once you find it.

The operation to build the array index from coordinates should be (y << 8 | z << 4 | x).  That uses bit-shifting, so if you don't understand it I recommend looking that term up.

 

Vanilla uses (x << 11 | z << 7 | y).  Moving y to the higher order bits allows us to express values larger than 127.  You can use this to generate up to 255 easily.  In theory, it's possible to make the world height go up even further, but I've not tested this.  My chunk constructor wouldn't care, but the storage system might.  Note that all that needs to happen for the constructor to do this is to make the array you pass in bigger (it gets the y height of the array by array.length/256).

Thanks a lot draco! <3

Thanks a lot draco! <3

 

Came as a result of someone needing blockIDs > 255 in their worldgen, so they posted on BinaryMage for some help and that was supplied, figured it was relevant here.