mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-11 10:11:09 +00:00
694a0740dc
* Parallax but better: Smooth movement cleanup (#66567)
* Alright, so I'm optimizing parallax code so I can justify making it do a
bit more work
To that end, lets make the checks it does each process event based.
There's two. One is for a difference in view, which is an easy fix since
I added a view setter like a year back now.
The second is something planets do when you change your z level.
This gets more complicated, because we're "owned" by a client.
So the only real pattern we can use to hook into the client's mob's
movement is something like connect_loc_behalf.
So, I've made connect_mob_behalf. Fuck you.
This saves a proc call and some redundant logic
* Fixes random parallax stuttering
Ok so this is kinda a weird one but hear me out.
Parallax has this concept of "direction" that some areas use, mostly
the shuttle transit ones. Set when you move into a new area.
So of course it has a setter. If you pass it a direction that it doesn't
already have, it'll start up the movement animation, and disable normal
parallax for a bit to give it some time to get going.
This var is typically set to 0.
The problem is we were setting /area/space's direction to null in
shuttle movement code, because of a forgotten proc arg.
Null is of course different then 0, so this would trigger a halt in
parallax processing.
This causes a lot of strange stutters in parallax, mostly when you're
moving between nearspace and space. It looks really bad, and I'm a bit
suprised none noticed.
I've fixed it, and added a default arg to the setter to prevent this
class of issue in future. Things look a good bit nicer this way
* Adds animation back to parallax
Ok so like, I know this was removed and "none could tell" and whatever,
and in fairness this animation method is a bit crummy.
What we really want to do is eliminate "halts" and "jumps" in the
parallax moveemnt. So it should be smooth.
As it is on live now, this just isn't what happens, you get jumping
between offsets. Looks frankly, horrible. Especially on the station.
Just what I've done won't be enough however, because what we need to do
is match our parallax scroll speed with our current glide speed. I need
to figure out how to do this well, and I have a feeling it will involve
some system of managing glide sources.
Anyway for now the animation looks really nice for ghosts with default
(high) settings, since they share the same delay.
I've done some refactoring to how old animation code worked pre (4b04f9012d). Two major
changes tho.
First, instead of doing all the animate checks each time we loop over a
layer, we only do the layer dependant ones. This saves a good bit of
time.
Second, we animate movement on absolute layers too. They're staying in
the same position, but they still move on the screen, so we do the same
gental leaning. This has a very nice visual effect.
Oh and I cleaned up some of the code slightly.
* Parallax but better: Smooth movement cleanup
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
60 lines
2.0 KiB
Plaintext
60 lines
2.0 KiB
Plaintext
/// This component behaves similar to connect_loc_behalf, but working off clients and mobs instead of loc
|
|
/// To be clear, we hook into a signal on a tracked client's mob
|
|
/// We retain the ability to react to that signal on a seperate listener, which makes this quite powerful
|
|
/datum/component/connect_mob_behalf
|
|
dupe_mode = COMPONENT_DUPE_UNIQUE
|
|
|
|
/// An assoc list of signal -> procpath to register to the mob our client "owns"
|
|
var/list/connections
|
|
/// The master client we're working with
|
|
var/client/tracked
|
|
/// The mob we're currently tracking
|
|
var/mob/tracked_mob
|
|
|
|
/datum/component/connect_mob_behalf/Initialize(client/tracked, list/connections)
|
|
. = ..()
|
|
if (!istype(tracked))
|
|
return COMPONENT_INCOMPATIBLE
|
|
src.connections = connections
|
|
src.tracked = tracked
|
|
|
|
/datum/component/connect_mob_behalf/RegisterWithParent()
|
|
RegisterSignal(tracked, COMSIG_PARENT_QDELETING, .proc/handle_tracked_qdel)
|
|
update_signals()
|
|
|
|
/datum/component/connect_mob_behalf/UnregisterFromParent()
|
|
unregister_signals()
|
|
UnregisterSignal(tracked, COMSIG_PARENT_QDELETING)
|
|
|
|
tracked = null
|
|
tracked_mob = null
|
|
|
|
/datum/component/connect_mob_behalf/proc/handle_tracked_qdel()
|
|
SIGNAL_HANDLER
|
|
qdel(src)
|
|
|
|
/datum/component/connect_mob_behalf/proc/update_signals()
|
|
unregister_signals()
|
|
// Yes this is a runtime silencer
|
|
// We could be in a position where logout is sent to two things, one thing intercepts it, then deletes the client's new mob
|
|
// It's rare, and the same check in connect_loc_behalf is more fruitful, but it's still worth doing
|
|
if(QDELETED(tracked?.mob))
|
|
return
|
|
tracked_mob = tracked.mob
|
|
RegisterSignal(tracked_mob, COMSIG_MOB_LOGOUT, .proc/on_logout)
|
|
for (var/signal in connections)
|
|
parent.RegisterSignal(tracked_mob, signal, connections[signal])
|
|
|
|
/datum/component/connect_mob_behalf/proc/unregister_signals()
|
|
if(isnull(tracked_mob))
|
|
return
|
|
|
|
parent.UnregisterSignal(tracked_mob, connections)
|
|
UnregisterSignal(tracked_mob, COMSIG_MOB_LOGOUT)
|
|
|
|
tracked_mob = null
|
|
|
|
/datum/component/connect_mob_behalf/proc/on_logout(mob/source)
|
|
SIGNAL_HANDLER
|
|
update_signals()
|