7 Commits

Author	SHA1	Message	Date
LemonInTheDark	cf02f62298	useless update_appearance reduction, emissive_blocker micro optimization (saves a second of init) (#71658) ... ## About The Pull Request [Saves 0.2 seconds of init time. 50% of emissive blockers](8318b648f6) Emissive blockers are a decent expense during init, even these, which are the ones that update outside of initialize. I've inlined them, removed some redundant vars and checks, reduced the arg count, and shifted some things around. This ends up saving 200ms, or 50% of its total cost. I also shifted mutable_appearance about a bit. it's not a massive saving, but it is technically faster [Prevents a few redundant appearance_updates, saves 0.8 seconds of init](5475cd778b) Prequisit info: update_appearance is decently expensive It's good then to only do it if we have a reason to, right? Me and moth were shooting the shit about just general init time, and we came up with the idea of tracking which update_appearances actually "worked" and which didn't. That bit comes later, let's enjoy the fruits of that work first First, holograms were calling update_appearance on process, for almost no reason. I patched the one event they don't already "react" to, and then locked it behind a change decection if. good for live, doesn't impact init. Next, decals. If you add a decal to something before it inits, it'll react to the after successful init signal. The trouble is the same atom could have its appearance updated from this MORE then once, since decals can be stacked on tiles, and signal unregisters don't work once the signal is sent. So we add a flag to track if we've had this happen to us or not, so it only happens once. saves 80 ms Power! lots of things call power_change on init, often more then once. We'll update appearance for each of those calls, even if only one is an actual change. That's silly, better to track what sort of power we're using for our appearance and go off that changing This was taking about 300ms. Really stupid Icon smoothing. After emissive blockers were added, any change to something's icon smoothing would lead to an update_appearance call. Nasty shit, specially cause of walls, which don't even use emissive blockers. Ok then, so we'll always update appearance for movables, and will allow turfs that are interested to hook it manually. Not many of those anyhow This is slightly a dev ux thing, but it saves 600ms so I think it's worth it. Rare case anyway Telecomms: telecomm machines were updating appearance on process. This is to cover for them turning on/off on process. Better then to just check if on actually changed. This cost adds up midgame, doesn't impact init tho Materials: There's this update_appearance call in material on_apply. it doesn't do anything. The logs will lie to you and say it does, but it's just like reapplying emissives. It doesn't need to exist Saves like 50ms Canisters: Live thing, lots of time wasted updating appearance for no reason, lets see if we change anything first yes? [Uses defines to wrap update_appearance for tracking](4fa82e1c9d) [Undoes _update_appearance changes, instead reccomends 2 regexes to use](a8c8fec57a) I need file and line number for my tracking, so I need to override update_appearance calls, and also preferably not require every override of update_appearance to handle dummy file + line args. So instead, I created a wrapper proc that checks to see if appearanaces match (they're unique remember, the two of the same visual appearance will be equivalent) The trouble is I can't intercept JUST proc calls, or JUST function definitions with defines. it needs to be both. So I renamed the /update_appearance proc to /_update_appearance this way I can capture old uses, and don't need to worry about merge/dev brain skew ~~It does mean that all update_appearance proc definitions now look weird tho. My profiling is leaking into dev ux. I wish I had better templating.~~ **The above is no longer being pr'd**, it's instead just recommended via a few regexes adjacent to the define. Smelled wrong anyhow [Adds a setter for panel_open, so I can update_appearance on it](cf1df8a69f) ## Why It's Good For The Game Speed	2022-12-20 00:51:52 -08:00
LemonInTheDark	a625fc8038	Cleans up the fallout from plane cube (#70235) ... * Cleans up the fallout from plane cube Alright. Makes cleaning bubbles respect planes Adds support for updating overlays on move, fixing an issue with pointing at items Adds better error messages for failing to provide args for mutable_appearance() Fixes a bug where string overlays were not respecting insertion order * Adds documentation for offset spokesman and offset_const * Better stack trace * Removes some redundant uses of cached MAs At this scale, attempting to cache MAs like this has 0 impact on anything And just makes things more messy then they need to be * ensures fullscreen objects START offset, so things are always proper * ensures chatmessages always have the right offset * fixes compile * whoops, the above lighting plane should actually be ABOVE the lighting plane * fixes compile, also cleans up the fire overlay a tad * Adds a unit test for plane masters that are shrunk by multiz being double shrunk This is slightly hacky because of how I'm handing the plane master group, but it's not THAT bad, and gives me some real good coverage * Properly targets the seethrough plane at the game world plate. This fixes unit tests, and also just makes more sense * whoops * oh * adds datum support for allocate(), cleans up a harddel from testing * Makes camera chunks index at 1, and also makes them support non powers of two sizes, since that was unneeded * fixes runtime in allocate	2022-10-20 09:00:02 +13:00
LemonInTheDark	23bfdec8f4	Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115) ... About The Pull Request I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.) This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering. I'll do my best to keep this compact, but there's only so much I can do. Sorry brother. Core idea OK: first thing. vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc. This is bad. But how to do better? It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly. We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed. But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect. Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on). That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly. Everything else is just gravy. About the Plane Cube Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane. We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live. As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well. Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you. About Plane Master Groups BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc) Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc. So we need to maintain a mirror of each plane for every map we have open. This was quite messy, so I've refactored it (and maps too) to be a bit more modular. Rather then storing a list of plane masters, we store a list of plane master group datums. Each datum is in charge of the plane masters for its particular map, both creating them, and managing them. Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to. Much better then the hardcoded pattern we used to use. So much duplicated code man. Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers. image In addition, I've added a debug ui for plane masters. It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays. It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live. In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc. It also comes with an info dump about the ui, and plane masters/relays in general. Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible. See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md. "Landing" planes Ok so I've explained the backend, but how do we actually land planes properly? Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use. This is just a lot of gruntwork, but it's occasionally more complex. Sometimes we need to cache a list of z layer -> effect, and then use that. Also a LOT of updating on z move. So much z move shit. Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags. This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday I also need to update mob overlays on move. I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order. The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet. It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point. Behavior changes We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it. So instead we display the other side as a ui element. It's worse, but not that bad. Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior. The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane. I don't really care, but it should be fixable, I think, given elbow grease. Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think. Why It's Good For The Game <visual candy> Fixes #65800 Fixes #68461 Changelog cl refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb /cl	2022-09-27 20:11:04 +13:00
LemonInTheDark	e5a2b0f16e	Micros the lighting subsystem (Saves a second of init) (#69838) ... About The Pull Request Micros lighting objects, and their creation We save a good bit of time by not walking space turfs adjacent to new objects. We also save some time with micros in the actual underlay update logic. I swear dude we spend like 0.8 seconds of init applying the underlay. I want threaded maptick already Micros lighting sources, and corner creation A: Corners were being passed just A turf, and then expected to generatecorners based on that. This is pointless. It is better to instead pass in the coords of the bottom left turf, and then build in a circle. This saves like 0.3 seconds B: We use so many damn datum vars in corner application that we just do not need to. This resolves that, since it pissed me off. It's pointless. Lets cache em instead There's some misc datum var caching going on here too. Lemme see... Oh and a bit of shortcutting for a for loop, since it was a tad expensive on its own. Also I removed the turfs list, because it does fucking nothing. Why is this still here. All my little optimizations save about 1 second of init I think Not great, but not bad, and plus actual lighting work is faster now too Why It's Good For The Game Speed	2022-09-27 09:56:35 +13:00
Kylerace	24efbd6525	changes most uses of SSvis_overlays.add_vis_overlay() inside of update_overlays() to true overlays (#57985)	2021-03-31 13:54:07 -07:00
deathride58	56896dfc8e	Makes light fixtures actually glow in the dark while on (And adds the necessary groundwork for other above lighting plane stuff) (#35879) ... * adds an above lighting layer, adds lighting overlays * fixes wonkiness with broken and burned lights * decreases overlay alpha a tad bit * i gotta test this - removes new() override from mutable_appearance * readds /mutable_appearance/New() for legacy behaviour	2018-02-24 00:46:43 -05:00
MrPerson	ff3f84ab81	Replaces /image with /mutable_appearance, where appropriate (#26518) ... In cases where you're creating an image to use as an overlay, it makes more sense to use a mutable_appearance if you can. The image will create a static appearance for not just the image but also each intermediate step if you change vars along the way. The mutable appearance avoids this unnecessary and expensive process. The only situation that requires an image instead of a mutable_appearance is if the overlay is supposed to be directional. MA's ignore direction while images don't. I dunno why, probably another BYOND-ism. I added a convenience function, mutable_appearance(), designed to emulate image(). Also went ahead and set the default plane of /mutable_appearance to FLOAT_PLANE because it's fucking 0 by default. Several overlays that were image() calls were changed to just text strings when I could. overlays += "string" has the same result as overlays += image(icon, "string") and saves a proc call.	2017-04-25 12:15:16 +02:00