3 Commits

Author	SHA1	Message	Date
LemonInTheDark	230d399671	Ventcrawling improvements, performance and visual (#66709) ... * Initial pipecrawl work Ok so pipecrawl images were updating EVERY TIME YOU MOVED This was not good mojo What I've done here is twofold First, I ensured pipecrawl updates only when the net changes. This breaks the current implementation, but I intend on fixing that Second, I moved our method of getting pipes to the spatial grid This isn't that great at the moment, but I intend on adding support for tracking entered/exited cells, which should make this much better * Much faster pipecrawling processing, niceties Adds a concept called a cell tracker datum. It manages a list of cells a passed in bound is "inside", and when queried will return a list of new cells, and old cells. Because we only really care about maintaining an absolute window of "CELLS WE ARE IN" and less about always removing cells we're not in, we can manage a second window to prevent moving up and down on a cell line causing a ton of updates. Uses this concept to optimize pipecrawling significantly, from 3ms per call before to roughly 0.03ms per call. Also moves pipecrawl images to their own plane, so they don't overlap ui elements * Pipecrawling effects niceties, direction help You can now move in more then one direction when pipecrawling This works as expected, if you hold up and left, move up for a while, and come to a fork, you'll go left Added some effects to pipecrawling. It'll darken the lighting plane slightly, so you get a nice effect instead of just fullbright. Also added a color matrix and drop shadow to the pipe images, this way they stand out a bit more. You now glide between pipe moves, rather then moving instantly. This doesn't effect your actual move rate, but it no longer feels jittery with say, 60fps * Bounds * Fixes runtimes, cache something somethign sonic speed * Reworks how being interested in the spatial grid is tracked Rather then checking multiple variables on the atom to consider, we instead check for the existence of a string key. This key is used by a list on the spatial grid subsystem to retrive a cached list of all of the atoms "types" Doing this requires doing a bit of extra work in important_recursive_contents code, but it allows us to separate being a part of the spatial grid from using important recursive contents, which is very nice. As a consequence, I've had to unroll some lazylist macros in important recursive contents logic. It's not ""that"" bad but it's not great either. Oh and this adds a slight cost to enter/exit cell, but it's minimal. Basically, rather then checking for different features of a grid member, we just iterate the list their string key points to. Very handy So there's an added cost of a list copy and all, but we save the headache of more types technically increasing the cost of addition/removal. I also made adding/removing from the grid into one "pulbic" proc rather then two different ones for each operation, because it was starting to get silly * waaa waa it doesn't compile * chord -> coord * Ensures important_recursive_contents is actually emptied on removal * Removes soul * Kyler's review Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> * Kyler's review 2 Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> * Kyler's review 3 Moves some procs around, improves some documentation, catches a few small issues Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>	2022-05-08 21:04:44 -07:00
LemonInTheDark	24326bc649	Hud Image Culling By Z Level: Theft edition (#65189) ... * makes hud images only apply by z level * makes some of the atom_hud procs have better names * fixes warning with the hud_user list and adds better documentation * better docs for hud_images * removes TODOs * docs for hud_list * adds support for linked z levels so mobs can see lower ones * fixes merge conflict and shittily makes only shocked airlocks get added * adds support for setting images in the hud as active and inactive * gets rid of unatomic spatial grid change * maybe i should actually try COMPILING my changes * fixes merge skew and makes it compile again * fixes huds refusing to remove from users who changed z level * improves z level and registration logic * fixes antag huds not appearing * Fixes antag huds not properly setting. We now use hud_list in init, so it needs to be set before the new call, not after. Not sure why the use of appearance key was split like this, but none else knows either so none can stop me * Ensures that hiding a basic appearance also hides the atom's active list too * Fixes antag huds going poof Ensures that remove_atom_from_hud will return false if the passed atom isn't managed by it This fixes antag huds disappearing randomly, since they assumed that if the parent call of remove_atom_from_hud returned true, we should delete ourselves. This is a safe assumption for them to make, since they should only ever have one atom. Does kinda bork if we call remove_atom_from_hud in a way that is unsure if the passed atom is actually in that list. We were forced into doing this by how atom huds use the qdeleting signal. * makes basic alternate_appearance's only update themselves when setting their hud image to active and makes them not add themselves to the global huds_by_category list * fixes mistake with hud_users list being set non associatively (bad) * as anything in bot path loops * Fixes merge skew problems * Makes bot paths non global This way they can show themselves to only the bot that "owns" them, ya feel me? * Fixes huds not showing up sometimes, cleans up some code Post Kapu's limb refactor, we were calling prepare_huds twice in a human init call chain. What was happening was this: call prepare_huds() // Human I gained a new hud image I set active hud icons to mirror it call prepare_huds() // Living I overwrote the new hud image I attempted to set active hud icons, which failed because it assumes this can never happen *cries* * Renames add_hud_to_atom to show_to My hope is this will make understanding hud code a bit easier, by tying the behavior to a "verb" more closely. Also renamed a few vars * remove_hud_from_mob -> hide_from * Nitpicks a few comments * Whoops/fuck/shit/damn it all/hhhhhhhhhhhh * Moves check down, improves stack trace a bit Co-authored-by: KylerAce <kylerlumpkin1@gmail.com>	2022-05-04 22:15:10 -07:00
Kylerace	d005d76f0b	Fixes Massive Radio Overtime, Implements a Spatial Grid System for Faster Searching Over Areas (#61422) ... a month or two ago i realized that on master the reason why get_hearers_in_view() overtimes so much (ie one of our highest overtiming procs at highpop) is because when you transmit a radio signal over the common channel, it can take ~20 MILLISECONDS, which isnt good when 1. player verbs and commands usually execute after SendMaps processes for that tick, meaning they can execute AFTER the tick was supposed to start if master is overloaded and theres a lot of maptick 2. each of our server ticks are only 50 ms, so i started on optimizing this. the main optimization was SSspatial_grid which allows searching through 15x15 spatial_grid_cell datums (one set for each z level) far faster than iterating over movables in view() to look for what you want. now all hearing sensitive movables in the 5x5 areas associated with each spatial_grid_cell datum are stored in the datum (so are client mobs). when you search for one of the stored "types" (hearable or client mob) in a radius around a center, it just needs to iterate over the cell datums in range add the content type you want from the datums to a list subtract contents that arent in range, then contents not in line of sight return the list from benchmarks, this makes short range searches like what is used with radio code (it goes over every radio connected to a radio channel that can hear the signal then calls get_hearers_in_view() to search in the radios canhear_range which is at most 3) about 3-10 times faster depending on workload. the line of sight algorithm scales well with range but not very well if it has to check LOS to > 100 objects, which seems incredibly rare for this workload, the largest range any radio in the game searches through is only 3 tiles the second optimization is to enforce complex setter vars for radios that removes them from the global radio list if they couldnt actually receive any radio transmissions from a given frequency in the first place. the third optimization i did was massively reduce the number of hearables on the station by making hologram projectors not hear if dont have an active call/anything that would make them need hearing. so one of hte most common non player hearables that require view iteration to find is crossed out. also implements a variation of an idea oranges had on how to speed up get_hearers_in_view() now that ive realized that view() cant be replicated by a raycasting algorithm. it distributes pregenerated abstract /mob/oranges_ear instances to all hearables in range such that theres at max one per turf and then iterates through only those mobs to take advantage of type-specific view() optimizations and just adds up the references in each one to create the list of hearing atoms, then puts the oranges_ear mobs back into nullspace. this is about 2x as fast as the get_hearers_in_view() on master holy FUCK its fast. like really fucking fast. the only costly part of the radio transmission pipeline i dont touch is mob/living/Hear() which takes ~100 microseconds on live but searching through every radio in the world with get_hearers_in_radio_ranges() -> get_hearers_in_view() is much faster, as well as the filtering radios step the spatial grid searching proc is about 36 microseconds/call at 10 range and 16 microseconds at 3 range in the captains office (relatively many hearables in view), the new get_hearers_in_view() was 4.16 times faster than get_hearers_in_view_old() at 10 range and 4.59 times faster at 3 range SSspatial_grid could be used for a lot more things other than just radio and say code, i just didnt implement it. for example since the cells are datums you could get all cells in a radius then register for new objects entering them then activate when a player enters your radius. this is something that would require either very expensive view() calls or iterating over every player in the global list and calling get_dist() on them which isnt that expensive but is still worse than it needs to be on normal get_hearers_in_view cost the new version that uses /mob/oranges_ear instances is about 2x faster than the old version, especially since the number of hearing sensitive movables has been brought down dramatically. with get_hearers_in_view_oranges_ear() being the benchmark proc that implements this system and get_hearers_in_view() being a slightly optimized version of the version we have on master, get_hearers_in_view_as() being a more optimized version of the one we have on master, and get_hearers_in_LOS() being the raycasting version currently only used for radios because it cant replicate view()'s behavior perfectly.	2021-12-16 19:49:27 -08:00