01-12-2019, 12:28 AM
I agree with almost everything you wrote here.
About optimization: the idea of coding into numbers doesn't sound too bad to me, however we should think _a bit_ now about layout of the numbers + the storage, to either let the compiler do optimizations right away or do them later (I can think of, for example, if the total actual block state (maybe even including some surrounding blocks) is encoder in a single number, I'd happily trade the few bits for a cache of known state transformations.
One possible option: a plugin registers a block, which has a method similar to javas hash code that combines all relevant state into a single number, (which also defines whether two block states are equal and so on). This should definitely be a fast hash and computed rather often. Additionally, we have a tick function, which takes the current state plus the surrounding blockarea and transforms it into some other state. If a plugin does not depend on neighboring blocks, it can mark itself as isolated, in which case no surrounding blockarea is passed in.
If the surrounding area changed, the block is marked as dirty (well if a block changed, it's surrounding blocks are marked dirty), in which case tick needs to be re-evaluated. Block state changes which aren't dirty could be looked up in a table that maps previous state to next state.
It's just an idea, but with a little bit more work into it, it could make ticking large areas really efficient because i would guess a lot of water simulation eg is pretty similar and could thus be optimized.
Also, a possible option of optimizing would be looking into ways to optimize data layout and computation make the compiler produce SIMD instructions, as that could potentially result in a fairly high performance gain.
About optimization: the idea of coding into numbers doesn't sound too bad to me, however we should think _a bit_ now about layout of the numbers + the storage, to either let the compiler do optimizations right away or do them later (I can think of, for example, if the total actual block state (maybe even including some surrounding blocks) is encoder in a single number, I'd happily trade the few bits for a cache of known state transformations.
One possible option: a plugin registers a block, which has a method similar to javas hash code that combines all relevant state into a single number, (which also defines whether two block states are equal and so on). This should definitely be a fast hash and computed rather often. Additionally, we have a tick function, which takes the current state plus the surrounding blockarea and transforms it into some other state. If a plugin does not depend on neighboring blocks, it can mark itself as isolated, in which case no surrounding blockarea is passed in.
If the surrounding area changed, the block is marked as dirty (well if a block changed, it's surrounding blocks are marked dirty), in which case tick needs to be re-evaluated. Block state changes which aren't dirty could be looked up in a table that maps previous state to next state.
It's just an idea, but with a little bit more work into it, it could make ticking large areas really efficient because i would guess a lot of water simulation eg is pretty similar and could thus be optimized.
Also, a possible option of optimizing would be looking into ways to optimize data layout and computation make the compiler produce SIMD instructions, as that could potentially result in a fairly high performance gain.