mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-03 13:32:17 +00:00
23bfdec8f4
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
205 lines
9.0 KiB
Plaintext
205 lines
9.0 KiB
Plaintext
|
|
/** # Beam Datum and Effect
|
|
* **IF YOU ARE LAZY AND DO NOT WANT TO READ, GO TO THE BOTTOM OF THE FILE AND USE THAT PROC!**
|
|
*
|
|
* This is the beam datum! It's a really neat effect for the game in drawing a line from one atom to another.
|
|
* It has two parts:
|
|
* The datum itself which manages redrawing the beam to constantly keep it pointing from the origin to the target.
|
|
* The effect which is what the beams are made out of. They're placed in a line from the origin to target, rotated towards the target and snipped off at the end.
|
|
* These effects are kept in a list and constantly created and destroyed (hence the proc names draw and reset, reset destroying all effects and draw creating more.)
|
|
*
|
|
* You can add more special effects to the beam itself by changing what the drawn beam effects do. For example you can make a vine that pricks people by making the beam_type
|
|
* include a crossed proc that damages the crosser. Examples in venus_human_trap.dm
|
|
*/
|
|
/datum/beam
|
|
///where the beam goes from
|
|
var/atom/origin = null
|
|
///where the beam goes to
|
|
var/atom/target = null
|
|
///list of beam objects. These have their visuals set by the visuals var which is created on starting
|
|
var/list/elements = list()
|
|
///icon used by the beam.
|
|
var/icon
|
|
///icon state of the main segments of the beam
|
|
var/icon_state = ""
|
|
///The beam will qdel if it's longer than this many tiles.
|
|
var/max_distance = 0
|
|
///the objects placed in the elements list
|
|
var/beam_type = /obj/effect/ebeam
|
|
///This is used as the visual_contents of beams, so you can apply one effect to this and the whole beam will look like that. never gets deleted on redrawing.
|
|
var/obj/effect/ebeam/visuals
|
|
///The color of the beam we're drawing.
|
|
var/beam_color
|
|
/// If set will be used instead of origin's pixel_x in offset calculations
|
|
var/override_origin_pixel_x = null
|
|
/// If set will be used instead of origin's pixel_y in offset calculations
|
|
var/override_origin_pixel_y = null
|
|
/// If set will be used instead of targets's pixel_x in offset calculations
|
|
var/override_target_pixel_x = null
|
|
/// If set will be used instead of targets's pixel_y in offset calculations
|
|
var/override_target_pixel_y = null
|
|
|
|
/datum/beam/New(origin, target, icon = 'icons/effects/beam.dmi', icon_state = "b_beam", time = INFINITY, max_distance = INFINITY, beam_type = /obj/effect/ebeam, beam_color = null, override_origin_pixel_x = null, override_origin_pixel_y = null, override_target_pixel_x = null, override_target_pixel_y = null)
|
|
src.origin = origin
|
|
src.target = target
|
|
src.icon = icon
|
|
src.icon_state = icon_state
|
|
src.max_distance = max_distance
|
|
src.beam_type = beam_type
|
|
src.beam_color = beam_color
|
|
src.override_origin_pixel_x = override_origin_pixel_x
|
|
src.override_origin_pixel_y = override_origin_pixel_y
|
|
src.override_target_pixel_x = override_target_pixel_x
|
|
src.override_target_pixel_y = override_target_pixel_y
|
|
if(time < INFINITY)
|
|
QDEL_IN(src, time)
|
|
|
|
/**
|
|
* Proc called by the atom Beam() proc. Sets up signals, and draws the beam for the first time.
|
|
*/
|
|
/datum/beam/proc/Start()
|
|
visuals = new beam_type()
|
|
visuals.icon = icon
|
|
visuals.icon_state = icon_state
|
|
visuals.color = beam_color
|
|
visuals.layer = ABOVE_ALL_MOB_LAYER
|
|
visuals.vis_flags = VIS_INHERIT_PLANE
|
|
visuals.update_appearance()
|
|
Draw()
|
|
RegisterSignal(origin, COMSIG_MOVABLE_MOVED, .proc/redrawing)
|
|
RegisterSignal(target, COMSIG_MOVABLE_MOVED, .proc/redrawing)
|
|
|
|
/**
|
|
* Triggered by signals set up when the beam is set up. If it's still sane to create a beam, it removes the old beam, creates a new one. Otherwise it kills the beam.
|
|
*
|
|
* Arguments:
|
|
* mover: either the origin of the beam or the target of the beam that moved.
|
|
* oldloc: from where mover moved.
|
|
* direction: in what direction mover moved from.
|
|
*/
|
|
/datum/beam/proc/redrawing(atom/movable/mover, atom/oldloc, direction)
|
|
SIGNAL_HANDLER
|
|
if(origin && target && get_dist(origin,target)<max_distance && origin.z == target.z)
|
|
QDEL_LIST(elements)
|
|
INVOKE_ASYNC(src, .proc/Draw)
|
|
else
|
|
qdel(src)
|
|
|
|
/datum/beam/Destroy()
|
|
QDEL_LIST(elements)
|
|
QDEL_NULL(visuals)
|
|
UnregisterSignal(origin, COMSIG_MOVABLE_MOVED)
|
|
UnregisterSignal(target, COMSIG_MOVABLE_MOVED)
|
|
target = null
|
|
origin = null
|
|
return ..()
|
|
|
|
/**
|
|
* Creates the beam effects and places them in a line from the origin to the target. Sets their rotation to make the beams face the target, too.
|
|
*/
|
|
/datum/beam/proc/Draw()
|
|
if(SEND_SIGNAL(src, COMSIG_BEAM_BEFORE_DRAW) & BEAM_CANCEL_DRAW)
|
|
return
|
|
var/origin_px = isnull(override_origin_pixel_x) ? origin.pixel_x : override_origin_pixel_x
|
|
var/origin_py = isnull(override_origin_pixel_y) ? origin.pixel_y : override_origin_pixel_y
|
|
var/target_px = isnull(override_target_pixel_x) ? target.pixel_x : override_target_pixel_x
|
|
var/target_py = isnull(override_target_pixel_y) ? target.pixel_y : override_target_pixel_y
|
|
var/Angle = get_angle_raw(origin.x, origin.y, origin_px, origin_py, target.x , target.y, target_px, target_py)
|
|
///var/Angle = round(get_angle(origin,target))
|
|
var/matrix/rot_matrix = matrix()
|
|
var/turf/origin_turf = get_turf(origin)
|
|
rot_matrix.Turn(Angle)
|
|
|
|
//Translation vector for origin and target
|
|
var/DX = (32*target.x+target_px)-(32*origin.x+origin_px)
|
|
var/DY = (32*target.y+target_py)-(32*origin.y+origin_py)
|
|
var/N = 0
|
|
var/length = round(sqrt((DX)**2+(DY)**2)) //hypotenuse of the triangle formed by target and origin's displacement
|
|
|
|
for(N in 0 to length-1 step 32)//-1 as we want < not <=, but we want the speed of X in Y to Z and step X
|
|
if(QDELETED(src))
|
|
break
|
|
var/obj/effect/ebeam/segment = new beam_type(origin_turf, src)
|
|
elements += segment
|
|
|
|
//Assign our single visual ebeam to each ebeam's vis_contents
|
|
//ends are cropped by a transparent box icon of length-N pixel size laid over the visuals obj
|
|
if(N+32>length) //went past the target, we draw a box of space to cut away from the beam sprite so the icon actually ends at the center of the target sprite
|
|
var/icon/II = new(icon, icon_state)//this means we exclude the overshooting object from the visual contents which does mean those visuals don't show up for the final bit of the beam...
|
|
II.DrawBox(null,1,(length-N),32,32)//in the future if you want to improve this, remove the drawbox and instead use a 513 filter to cut away at the final object's icon
|
|
segment.icon = II
|
|
segment.color = beam_color
|
|
else
|
|
segment.vis_contents += visuals
|
|
segment.transform = rot_matrix
|
|
|
|
//Calculate pixel offsets (If necessary)
|
|
var/Pixel_x
|
|
var/Pixel_y
|
|
if(DX == 0)
|
|
Pixel_x = 0
|
|
else
|
|
Pixel_x = round(sin(Angle)+32*sin(Angle)*(N+16)/32)
|
|
if(DY == 0)
|
|
Pixel_y = 0
|
|
else
|
|
Pixel_y = round(cos(Angle)+32*cos(Angle)*(N+16)/32)
|
|
|
|
//Position the effect so the beam is one continous line
|
|
var/a
|
|
if(abs(Pixel_x)>32)
|
|
a = Pixel_x > 0 ? round(Pixel_x/32) : CEILING(Pixel_x/32, 1)
|
|
segment.x += a
|
|
Pixel_x %= 32
|
|
if(abs(Pixel_y)>32)
|
|
a = Pixel_y > 0 ? round(Pixel_y/32) : CEILING(Pixel_y/32, 1)
|
|
segment.y += a
|
|
Pixel_y %= 32
|
|
|
|
segment.pixel_x = origin_px + Pixel_x
|
|
segment.pixel_y = origin_py + Pixel_y
|
|
CHECK_TICK
|
|
|
|
/obj/effect/ebeam
|
|
mouse_opacity = MOUSE_OPACITY_TRANSPARENT
|
|
anchored = TRUE
|
|
var/datum/beam/owner
|
|
|
|
/obj/effect/ebeam/Initialize(mapload, beam_owner)
|
|
owner = beam_owner
|
|
return ..()
|
|
|
|
/obj/effect/ebeam/update_overlays()
|
|
. = ..()
|
|
var/mutable_appearance/emmisive = emissive_appearance(icon, icon_state, src)
|
|
emmisive.transform = transform
|
|
. += emmisive
|
|
|
|
/obj/effect/ebeam/Destroy()
|
|
owner = null
|
|
return ..()
|
|
|
|
/obj/effect/ebeam/singularity_pull()
|
|
return
|
|
/obj/effect/ebeam/singularity_act()
|
|
return
|
|
|
|
/**
|
|
* This is what you use to start a beam. Example: origin.Beam(target, args). **Store the return of this proc if you don't set maxdist or time, you need it to delete the beam.**
|
|
*
|
|
* Unless you're making a custom beam effect (see the beam_type argument), you won't actually have to mess with any other procs. Make sure you store the return of this Proc, you'll need it
|
|
* to kill the beam.
|
|
* **Arguments:**
|
|
* BeamTarget: Where you're beaming from. Where do you get origin? You didn't read the docs, fuck you.
|
|
* icon_state: What the beam's icon_state is. The datum effect isn't the ebeam object, it doesn't hold any icon and isn't type dependent.
|
|
* icon: What the beam's icon file is. Don't change this, man. All beam icons should be in beam.dmi anyways.
|
|
* maxdistance: how far the beam will go before stopping itself. Used mainly for two things: preventing lag if the beam may go in that direction and setting a range to abilities that use beams.
|
|
* beam_type: The type of your custom beam. This is for adding other wacky stuff for your beam only. Most likely, you won't (and shouldn't) change it.
|
|
*/
|
|
/atom/proc/Beam(atom/BeamTarget,icon_state="b_beam",icon='icons/effects/beam.dmi',time=INFINITY,maxdistance=INFINITY,beam_type=/obj/effect/ebeam, beam_color = null, override_origin_pixel_x = null, override_origin_pixel_y = null, override_target_pixel_x = null, override_target_pixel_y = null)
|
|
var/datum/beam/newbeam = new(src,BeamTarget,icon,icon_state,time,maxdistance,beam_type, beam_color, override_origin_pixel_x, override_origin_pixel_y, override_target_pixel_x, override_target_pixel_y )
|
|
INVOKE_ASYNC(newbeam, /datum/beam/.proc/Start)
|
|
return newbeam
|
|
|
|
|