As discussed many years ago in #2551, no one actually knows what this property actually means. It definitely isn't the conventionally expected definition of 'solid' found in the real world, as signs are solid but flower pots are not.
if there's no state data to encode, we can avoid useless calls and object allocations.
For the best cases (blocks which don't use state data at all) this improves the performance of getStateId() by more than 10x.
Blocks which use one or the other benefit by a smaller but still significant margin.
Farmland can end up scanning up to 162 blocks looking for water in the worst case. This is obviously not great for huge farms where there are thousands of blocks of the stuff.
In most farms, the water won't be moved, and nor will the farmland. This means that we can avoid this costly search on random updates.
This PR implements a cache using blockstate data (only possible in PM5) which stores an index mapping to a coordinate offset where water was previously found by this farmland block. This allows the farmland to avoid water searching entirely in most cases.
This is a colossal improvement as compared to scanning the whole 9x2x9 area every time, which, on average, scans about 40 blocks to find water if the water is at the same Y coordinate. In real terms this translates into about a 8x performance improvement for farmland (see timings below).
xxhash is generally well known for its hash key properties, so this is a suitable use case.
We XOR the state data with a partial hash of xxh3(typeID), which provides sufficient hash distribution regardless of the size of state data.
The previous method started to break down as the number of bits exceeded the number of significant bits of type ID (about 10 currently).
As well as being better for hash distribution regardless of state data size, this also reduces the load factor of RuntimeBlockRegistry to 1.08 (previously around 1.24), which is a nice bonus.
this makes it marginally faster, since we can skip all permutations containing invalid type data.
I measured a performance improvement of about 20% across all blocks.
In addition, this makes it easier to locate where a problem is coming from if invalid inputs are accepted.
this switches from a 'can be supported by' concept to a 'can stay at this position' paradigm, which requires way less boilerplate code.
there may be further improvements we can make from here, such as adding traits, but this is a good first step.
since most blocks have no state data, their lower 8 bits of state data were all zero.
This makes state IDs a bit more distributed for minimal cost.
I considered flipping these around and using type ID in the lower bits directly, but this worsened distribution for walls.
In the worst case, largest number of collisions drops from 11 to 5 with this change, and the number of states with unique hash keys increased from 3518 to 4461 (out of 7638). This is still a long way from perfect, but it's a decent improvement, improving the overall load factor from 1.6 to 1.3.
related to #5604
For blocks, we now use 'block-item state' and 'block-only state', which should be much clearer for people implementing custom stuff.
'block-item state', as the name suggests, sticks to the item when the block is acquired as an item.
'block-only state' applies only to the block and is discarded when the block is acquired as an item.
'type data' for items was also renamed, since 'type' is too ambiguous to be anything but super confusing.
This was first attempted in f64dc01bd1, but reverted, since I hadn't considered how to handle stripping state data from blocks.
This removes the abusable API RuntimeBlockStateRegistry::fromTypeId() and related methods. These were only used to allow ItemBlocks to magically start referencing other blocks if the blocks were overridden by a plugin, but this was never a well-supported use-case anyway.
Instead of relying on RuntimeBlockStateRegistry, we remember the state that the block had during its constructor, and use that to normalize the non-item properties for asItem().
closes#5609
This reverts commit f64dc01bd1.
I forgot that the ItemBlock constructor implicitly strips off any states
of the origin block, which is something that we unfortunately can't do
any other way right now, since the blocks don't remember their default
states.
