Files
Bubberstation/code/_onclick
LemonInTheDark 07882b23cc Converts parallax to pixel offsets, saves a bunch of cpu time, makes things nicer on clients too (#83395)
## About The Pull Request

Right now parallax is like a quarter of SSinput, which is BAD. It's so
high mostly because of the animates we need to do, but also due to the
cost of setting screen_loc.


![image](https://github.com/tgstation/tgstation/assets/58055496/8e4ec4b7-2101-4dca-91b8-4db9e79de7c4)

This sucks. The default step is to reduce the poll rate of the effect,
but I don't want to do that because it SUCKS. Sooooo how can we
optimize.

Well, if we stop thinking in terms of screen_loc, which is a string
(tree shit) and also unanimatable, and start working in pixel offsets,
this'd be a way cheaper.

We can make that happen by sticking all our parallax layers on one rock
screen object. Then they have relative positions and can be pixel offset
(I have stolen this concept wholesale from Ter)

This works unreasonably well, roughly a 65% cost reduction. S good shit.


![image](https://github.com/tgstation/tgstation/assets/58055496/1e6c4455-a13b-44c3-bf59-71ef26cac9fd)

While I'm here...

[uses KEEP_TOGETHER to reduce clientside load, makes the flying
animation
better.](52610398e2)

We were individually rendering all like fucking 24 480x480 overlays on
all 5 parallax layers, which means we had to apply our transform to EACH
ONE. This has GOTTA suck shit for clients, so let's... not? Should help.

The existing flying animation makes me depressed. it has some very
visible stutter, and jumps around a lot.

We can deal with the starting stutter by avoiding starting a new
animation on the layer until the old one is finished. This is what was
SUPPOSED to be happening, but because we fired one timer for all the
layers, they'd desync and jump in ugly ways.

This means we need to use one timer per layer, which does induce more
cost then I'd like. IDK how I feel about this to be honest.

I try and reduce ending weirdness by unscaling time at the end, so
different aspects don't slow down at different rates.

Speed on the parallax animation was weird, it'd spike up, then dip down
in flight.
This was because the percieved rate of change from the quad easing was
closer to 2x the existing.
I've handled this by halving the animation time in the loop

Oh also there's no sense calling the update animation proc if we are
coming to a stop, and thus have no follow up animation.


## Changelog

🆑 LemonInTheDark
refactor: I have reworked how parallax and its animations (space travel)
work. Please report any bugs lads!
/🆑

---------

Co-authored-by: san7890 <the@san7890.com>
2024-05-27 10:43:25 -06:00
..
2024-05-19 21:33:24 -06:00
2024-05-16 19:54:00 -07:00
2024-04-16 17:48:03 -06:00
2024-04-16 17:48:03 -06:00
2024-05-16 19:54:00 -07:00
2024-04-16 17:48:03 -06:00