01-16-2019, 01:10 AM
I don't quite understand what you mean altogether. Are you proposing that we add another translation for the BlockState, so that the data is represented:
1. In BlockArea: A single block is represented by a single number, index into per-BlockArea Palette
2. In Palette: A single index maps to "BlockTypeName" and "BlockStateIndex", an index into a global BlockStatePalette
3. In BlockStatePalette: A single index corresponds to the entire BlockState representation (map of key -> value)
In code:
Anyway, such a proposal is possible to implement later on as an optimization, and I don't think the added complexity is worth the effort and savings. I've done a bit of calculations, here's the raw math.
A chunk section (16*16*16 blocks) in the current pre-1.13 format uses exactly 8 KiB of RAM (16 * 16 * 16 blocks, each block 12 bits of type and 4 bits of meta)
A chunk section in the 1.13 format with a local palette can use from 16 KiB of RAM through 2 KiB of RAM downto 0.5 KiB of RAM (16 * 16 * 16 blocks, each block either 32-bit, 4-bit or 1-bit; exact bit-size is governed by the amount of different block types). So we could end up with up to twice as much RAM requirement in the worst case, but also 16 times less RAM in the best case. Considering the 0.5 KiB, storing the BlockStates as a string -> string map could mean a lot of memory, but there will only be 2 blocks in such a case anyway, so not too much of a BlockState to store. In the 16 KiB size, there could be up to 4K different blocks, but my opinion is that many of those will not have any BlockState at all, so the memory used will be reasonable as well.
Basically, I don't suppose that changing the internal representation to one with the local palette would change the RAM requirements dramatically.
1. In BlockArea: A single block is represented by a single number, index into per-BlockArea Palette
2. In Palette: A single index maps to "BlockTypeName" and "BlockStateIndex", an index into a global BlockStatePalette
3. In BlockStatePalette: A single index corresponds to the entire BlockState representation (map of key -> value)
In code:
class Palette
{
struct BlockDef
{
std::string mBlockTypeName; // such as "minecraft:acacia_door"
size_t mBlockStateIndex; // Index into global BlockStatePalette
};
std::map<UInt32, BlockDef> mBlockTypeMap;
};
using BlockState = map<std::string, std::string>; // For simplicity, only consider strings as values for now
class BlockStatePalette
{
std::map<size_t, BlockState> mBlockStateMap;
};
// global:
BlockStatePalette gBlockStatePalette;
class BlockArea
{
UInt32 mBlocks[]; // To be replaced by smaller numbers when possible
Palette mPalette;
std::pair<const AString &, const BlockState &> block(const Vector3i & aPos)
{
UInt32 paletteIndex = mBlocks[...];
const AString & blockTypeName = mPalette.mBlockTypeMap[paletteIndex].mBlockTypeName;
const BlockState & blockState = gPalette.mBlockStateMap[mPalette.mBlockTypeMap[paletteIndex].mBlockStateIndex];
return {blockTypeName, blockState};
}
};
I hope the code for BlockArea::block() illustrates the concept enough.Anyway, such a proposal is possible to implement later on as an optimization, and I don't think the added complexity is worth the effort and savings. I've done a bit of calculations, here's the raw math.
A chunk section (16*16*16 blocks) in the current pre-1.13 format uses exactly 8 KiB of RAM (16 * 16 * 16 blocks, each block 12 bits of type and 4 bits of meta)
A chunk section in the 1.13 format with a local palette can use from 16 KiB of RAM through 2 KiB of RAM downto 0.5 KiB of RAM (16 * 16 * 16 blocks, each block either 32-bit, 4-bit or 1-bit; exact bit-size is governed by the amount of different block types). So we could end up with up to twice as much RAM requirement in the worst case, but also 16 times less RAM in the best case. Considering the 0.5 KiB, storing the BlockStates as a string -> string map could mean a lot of memory, but there will only be 2 blocks in such a case anyway, so not too much of a BlockState to store. In the 16 KiB size, there could be up to 4K different blocks, but my opinion is that many of those will not have any BlockState at all, so the memory used will be reasonable as well.
Basically, I don't suppose that changing the internal representation to one with the local palette would change the RAM requirements dramatically.
