I previously avoided this due to being unsure of the effects; however, it's clear that we already use typed properties on Threaded things in other places anyway, and the only known issues are with uninit properties, and arrays.
instead, use a const array of the offsets and add them to the coordinates, which avoids the allocations.
In synthetic benchmarks, this method takes 40-50% less CPU time by eliding ZEND_INIT_ARRAY and ZEND_ADD_ARRAY opcodes. In practice, the benefit will likely be much smaller (perhaps even irrelevant).
in cases like PopulationTask it makes more sense to store the coordinates separately where they can be stored more efficiently (once instead of 9 times)
In addition, PopulationTask shouldn't need to serialize an empty chunk just to copy coordinates.
I've made changes like this in other areas already in preparation for the day when chunks no longer contain their coordinates, so this brings us one step closer to that goal.
this restores SimpleChunkManager's behaviour to PM3, removing the need for GeneratorChunkManager (although I'm dubious whether SubChunkExplorer makes any sense in there any more now that we have morton in the mix).
when setBlockSkyLightArray/setBlockLightArray was used, currentLightArray would retain a reference to the old light array, which would cause false readings if SubChunkExplorer didn't move away from that subchunk and back.
This causes a small degradation of performance, but I think it can be implemented differently anyway.
This also fixes#3816.
this produces a major performance improvement for large render distances, and reduces the impact of lighting calculation to zero on servers which have random blockupdates turned off.
Various bugs existed for a while with stuff using chunk managers instead of worlds when interacting with terrain due to a behavioural inconsistency between World::getChunk() (return from cache or load from disk), and SimpleChunkManager::getChunk() (return from cache only). This change brings the two in line.
World::getOrLoadChunk() has been added as a replacement, which has the same behaviour as the old getChunk() and also makes it more obvious that there is an issue with code using it during refactoring.
this solves multiple architectural issues:
- improves reusability by avoiding having old state info stick around to fuck stuff up
- prevents access to propagation state from outside of propagation
this also reduces the latent memory usage of light-updates after they have been used.
TODO: we could probably change LightPropagationContext to LightPropagator and move all the propagation-specific code into it if we can solve the subchunk-iterator and effective light problems.
this new form allows skipping some useless checks during sky light calculation and also allows getting rid of the last hard dependency on core Block classes.
We're getting real close to native light now.
I accidentally added this during a separation of my local changes, but it's useful anyway, so we should use it.
This removes BlockLightUpdate's implicit dependency on Block, which is a
step towards native light.
it's useful to have an immutable stub around for the sake of feeding back dummy read values, but for write values it has to barf instead of being quiet.
There's still some issues with LightArray which I don't currently have a solution for, but I'm thinking about separating light storage from chunks anyway.
copy-on-write and zero-layer SubChunk objects are much easier to manage and have less cognitive overhead.
obviously, the goal is to get rid of EmptySubChunk completely, but right now it does still serve a purpose (filling in dummy values for reading out-of-bounds on chunks), and that's a problem that takes a little more work to fix.
this is more efficient (less data copied for ITC), fixes#2873, and also fixes terrain changes during task run getting overwritten.
This still leaves the problem that the light information provided may be out of date by the time the task completes, but this is nonetheless a step forward.
