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 it's so great when you're chasing down hard incremental improvements and a huge systemic improvement falls into your lap.
Doing a big many*-agents update, initial profiling said "page faults are eating your lunch", I was looking at *writing a scheduler* (oh no), but then realized I can just partition the agents into active and inactive sets, inactive is easily thousands of times bigger than active.
*many being around... uhhh several thousand to several million depending on how you count?
@eniko piling up low hanging fruit like "use the right data structure" is kind of, "do it whenever" even if it doesn't "solve" anything.
I struggled earlier in my career with "avoiding premature optimization" until I went back to the source and found that doing something roughly optimally wasn't what they were talking about, but rather making things more complicated/fragile in the nane of making it slightly faster.
@kevingranade yeah, its tweaking the heck out of an algorithm until its completely impossible to follow rather than "wait i can just avoid doing 97.5% of this work"
i actually did one optimization that got a couple percentage points increase by making my algorithm simpler and just doing a little extra up-front work when removing blocks
Eniko Fox
mort
Oblomov
Kevin Granade
KarakSindru (He/Him)
Richard Hendricks
kajina cyborg mouse 
Simon Brenner
MrL314 💚 (#SMKDX)
Erika
Jonathan Evraire