Not enjoying my time with sunlight propagation in block game but at least it got me to optimize the MarkReachable* function in the lighting propagator which was taking up a third of the runtime for lighting propagation so that's something I guess
*because I propagate lighting to diagonals and corners of all 3x3 neighbors of a block to get more spherical lighting the propagator has to know if those neighbors are actually reachable from the current block which is what MarkReachable does
The real solution to all of this is to shove the propagator and indeed chunk generation into background threads and I will do that eventually but that's a massive commitment that doesn't mesh with my "make it exist first you can make it good later" philosophy
But also I'd like any chugging to be on the order of less than a full second of screen freeze >_>
update: my intuition on a queue being faster for sunlight propagation than a stack was correct, with a queue taking 96.5% the time of the stack
not gonna win any awards for speed increases there but i'll take a free 4%
optimized sunlight propagation using heightmaps since i had to add it for block removal anyway and now it takes only 2.5% the time it took before lmao
@eniko OMG, you just solved a problem that has been annoying me about my game's lighting calculations
For sunlight, I have some stupid code that checks like, "if this block is above some depth level and has no tiles up to N tiles above it, it's sunlit". And I mean, it works, but it's stupid. It makes it impossible to build large dark rooms overground and it makes deep holes in the terrain too dark.
The solution seems so obvious now that you pointed it out: maintain a heightmap. Thanks!
Eniko Fox
mort