mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-13 11:12:14 +00:00
cf02f62298
## 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
49 lines
2.6 KiB
Plaintext
49 lines
2.6 KiB
Plaintext
// Mutable appearances are an inbuilt byond datastructure. Read the documentation on them by hitting F1 in DM.
|
|
// Basically use them instead of images for overlays/underlays and when changing an object's appearance if you're doing so with any regularity.
|
|
// Unless you need the overlay/underlay to have a different direction than the base object. Then you have to use an image due to a bug.
|
|
|
|
// Mutable appearances are children of images, just so you know.
|
|
|
|
// Mutable appearances erase template vars on new, because they accept an appearance to copy as an arg
|
|
// If we have nothin to copy, we set the float plane
|
|
/mutable_appearance/New(mutable_appearance/to_copy)
|
|
..()
|
|
if(!to_copy)
|
|
plane = FLOAT_PLANE
|
|
|
|
/** Helper similar to image()
|
|
*
|
|
* icon - Our appearance's icon
|
|
* icon_state - Our appearance's icon state
|
|
* layer - Our appearance's layer
|
|
* atom/offset_spokesman - An atom to use as reference for the z position of this appearance.
|
|
* Only required if a plane is passed in. If this is not passed in we accept offset_const as a substitute
|
|
* plane - The plane to use for the appearance. If this is not FLOAT_PLANE we require context for the offset to use
|
|
* alpha - Our appearance's alpha
|
|
* appearance_flags - Our appearance's appearance_flags
|
|
* offset_const - A constant to offset our plane by, so it renders on the right "z layer"
|
|
**/
|
|
/proc/mutable_appearance(icon, icon_state = "", layer = FLOAT_LAYER, atom/offset_spokesman, plane = FLOAT_PLANE, alpha = 255, appearance_flags = NONE, offset_const)
|
|
var/mutable_appearance/appearance = new()
|
|
appearance.icon = icon
|
|
appearance.icon_state = icon_state
|
|
appearance.layer = layer
|
|
appearance.alpha = alpha
|
|
appearance.appearance_flags |= appearance_flags
|
|
if(plane != FLOAT_PLANE)
|
|
// You need to pass in some non null object to reference
|
|
if(isatom(offset_spokesman))
|
|
// Note, we are ok with null turfs, that's not an error condition we'll just default to 0, the error would be
|
|
// Not passing ANYTHING in, key difference
|
|
SET_PLANE_EXPLICIT(appearance, plane, offset_spokesman)
|
|
// That or I'll let you pass in a static offset. Don't be stupid now
|
|
else if(!isnull(offset_const))
|
|
SET_PLANE_W_SCALAR(appearance, plane, offset_const)
|
|
// otherwise if you're setting plane you better have the guts to back it up
|
|
else
|
|
stack_trace("No plane offset passed in as context for a non floating mutable appearance, things are gonna go to hell on multiz maps")
|
|
else if(!isnull(offset_spokesman) && !isatom(offset_spokesman))
|
|
stack_trace("Why did you pass in offset_spokesman as [offset_spokesman]? We need an atom to properly offset planes")
|
|
|
|
return appearance
|