mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-23 23:24:55 +01:00
LemonInTheDark
546dc7fdfa
## About The Pull Request [cameras should actually show all of their view](https://github.com/tgstation/tgstation/commit/a8ef0f3bd7f16e590b9fae193f645c6cb6255f8f) Melb fucked up luminosity a bit (cries) [Implements camera range as the deciding factor for who can see a chunk](https://github.com/tgstation/tgstation/commit/bf4f9776dfce1c15e756ae1933a96ff0cff2dbf0) This allows us to safely modify chunk size (which I do, down to 8, which increases the actual cost involved in doing a full z update, but decreases the cost per chunk significantly) I use the range to macro optimize chunk New, we can safely use a bounding box instead of multiple urange calls and get about 1/3 the performance hit, even with a lower range (and thus 4x as many chunks) Standard caching and such applies [Fixes cameras not looking down correctly](https://github.com/tgstation/tgstation/commit/99b23f25203f34f04c0f92bb7d191699b91a439a) [Implements yielding support for individual chunks](https://github.com/tgstation/tgstation/commit/bdd2d01106465b8498307c16f83e9dd90706652a) This should functionally remove lagspikes from the cameras subsystem, which just leaves the problem of ais flying around. Much better tick obedience: https://github.com/user-attachments/assets/607d61a4-ad96-450c-acdf-10da967ab49b I tested this pr with #94522 to confirm that halving chunk sizes would have a benefit, see below: <img width="364" height="176" alt="image" src="https://github.com/user-attachments/assets/19f3ae7f-408b-4da5-8e38-a691030138fe" /> <img width="462" height="195" alt="image" src="https://github.com/user-attachments/assets/492b93bf-93ae-4227-9c6d-c5b2f0be9711" /> <img width="469" height="229" alt="image" src="https://github.com/user-attachments/assets/dba92982-09e4-4c3a-96e2-15e1a299676b" /> <img width="444" height="233" alt="image" src="https://github.com/user-attachments/assets/40b1e0dc-c03a-4acd-bba9-f1e4c68bffad" /> Things to note: Mean cost of finding turfs goes from 2ms to 1ms Max cost of finding turfs goes down by somewhere between 30% and 50%. I'd call this worthwhile, even if total cost of updating has gone up slightly. [Properly manages the camera refs in chunks](https://github.com/tgstation/tgstation/pull/94530/commits/00c97183ca83a91d95b9afcde70814c36a8f9a5e) [00c9718](https://github.com/tgstation/tgstation/pull/94530/commits/00c97183ca83a91d95b9afcde70814c36a8f9a5e) Turns out our solution for moving cameras in chunk code was to just... NOT CARE!! This means any moving camera is going to cause hard deletes. This was an issue during unit tests because of a stripping unit test. I suspect it only showed up here because I reduced the chunk size so we actually enter/leave a new set of chunks. I fixed this by reworking things to use a "leaving/joining" pattern. There's some other stuff here, mostly cleaning up old copypasta'd cruft in the code adjacent to moving cameras. I also changed the cameras and processing cameras alists back into lists, mostly for the sake of vv ability this didn't actually break anything. The harddel wasn't showing up because it was a number keyed alist, and reference tracking isn't built to find those (yet, pr up) ## Why It's Good For The Game I want AIs flying around to not cause massive lag spikes. That + the camera subsystem are one of like 4 things that's causing reliable tidi on live and it makes me upset. ## Changelog 🆑 fix: Cameras should work a little better (won't fail in the dark, will display multiz correctly refactor: Changed how static turf generation thinks about cameras. Shouldn't break anything but it MIGHT so keep an eye out for that. The chunks we use to divvy up the world for them are also 1/4th the area now, which should make flying around as ai less lagsikey /🆑 --------- Co-authored-by: Lucy <lucy@absolucy.moe>