mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-16 20:52:33 +00:00
32c31b8fc0
* Lighting source refactor (Tiny) (#73284) ## About The Pull Request I'm doing two things here. Let's get the boring bit out of the way. Lighting source updates do three distinct things, and those things were all in one proc. I've split that one proc into three, with the first two feeding into the third. Second, more interesting thing. An annoying aspect of our lighting system is the math we use for calculating luminosity is hardcoded. This means that we can't have subtypes that are angled, or that have squared falloff, etc. All has to look the same. This sucks, and it shows. It has to be, goes the thinking, because we need very fast lookups that OOP cannot provide. We can't bog down the main equation with fluff, because the main equation needs to be really speedy. The thing about this equation is the only variants on a turf to turf basis is exactly how far turfs are from the center. So what if, instead of doing the math in our corner worker loop, we build lookup tables to match our current source's state. The tables, like a heatmap, could encode the lighting of any point along the line. This is actually faster then doing the math each time, because the list generation can be cached. It also means we've pulled the part we want to override out of hotcode. It's cheap to override now, and a complex subtype, with angles and such would have no impact on the typical usage. So the code's faster, easier to read, and more extensible. And we can do stuff like squared falloff for some lights in future without breaking others. Winning! ## Why It's Good For The Game Winning * Lighting source refactor (Tiny) --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>