Getting Mad at Parallax (Includes Boomerspace!) (#95382)

## About The Pull Request

I want to do stuff with parallax (like placing stuff in the backdrop and
moving it around), but I'm in my not doing 100 things in one pr arc so
we're doing this piecemeal.

To start, I wanted to try adding oldspace back as a parallax layer. This
is something I was considering when it was first removed but never got
around to, so here we are.

I started by [writing a rust
program](https://github.com/LemonInTheDark/old_space_gen) to fabricate
the required icon state, then realized that all the different parts of
space have their own animation delays. There's no way I could make one
icon state with all them looping, so instead I split them up into
multiple components and then overlayed them together.

This works, but is infeasible (my gpu died) at the scale required for
parallax (17 480x480 sets, 15 unique delays per 1 set) so I used render
targets to render one copy, then mirror it to the rest of the overlays.
This works wonderfully, and gets us down to (on my machine) a gpu cost
comprable with about medium parallax intensity.

I'm open to making these tile bound but I thought making them look "far
away" feels better.

In the process of all this I got very mad at the existing parallax code,
soooooooo

Parallax layers are no longer stored on the client, they are stored on
and managed by the parallax home atom that holds them for display. Said
atom also tracks all the information about how they are selected.

Parallax layers no longer take a hud as input, instead expecting a
client. (we were just swapping them back and forth and I thought it was
dumb).

Parallax no longer tries to support passing in a mob that does not
actually own the hud it is displayed on. This feature wasn't even being
used anymore because it was fully broken, so all it was doing was making
the code worse.

Parallax no longer has to do a full refresh anytime something about WHAT
layers are displayed might have changed. We cache based off the
variables we care about, and use the change in state to determine what
should happen (this is improved by moving "rendering the layers" fully
to the control of the home datum).

Parallax no longer directly modifies the hud's plane masters, instead
relying on trait based signals to manipulate them (this avoids wasted
time in the common event of a needless parallax prefs check).

Parallax no longer has 2 procs that are only called together to
"remove/readd/update" the layers, instead doing both in a new check()
proc.

Cleans up some plane master cruft to do with tracking/managing huds
(might break, tested, think it's fine).

## Why It's Good For The Game


https://github.com/user-attachments/assets/79138a0f-9f6d-447d-843e-0d237db13276

## Changelog
🆑
add: Added an option for rendering space parallax with old space sprites
(the ones from before we invented parallax), they're animated and I feel
quite pretty.
fix: Space parallax should hopefully behave a little more consistently
now
refactor: Rewrote a lot of how space parallax handled itself, please
yell at me if any bugs make themselves known
/🆑
This commit is contained in:
LemonInTheDark
2026-03-19 18:46:30 -07:00
committed by GitHub
parent d03ae827f4
commit 3729ee3ef3
16 changed files with 320 additions and 194 deletions
-7
View File
@@ -186,8 +186,6 @@
///A lazy list of atoms we've examined in the last RECENT_EXAMINE_MAX_WINDOW (default 2) seconds, so that we will call [/atom/proc/examine_more] instead of [/atom/proc/examine] on them when examining
var/list/recent_examines
var/list/parallax_layers
var/list/parallax_layers_cached
var/atom/movable/screen/parallax_home/parallax_rock
///this is the last recorded client eye by SSparallax/fire()
var/atom/movable/movingmob
@@ -196,13 +194,8 @@
var/dont_animate_parallax
/// Direction our current area wants to move parallax
var/parallax_movedir = 0
/// How many parallax layers to show our client
var/parallax_layers_max = 4
/// Timers for the area directional animation, one for each layer
var/list/parallax_animate_timers
/// Do we want to do parallax animations at all?
/// Exists to prevent laptop fires
var/do_parallax_animations = TRUE
///Are we locking our movement input?
var/movement_locked = FALSE
-2
View File
@@ -645,8 +645,6 @@ GLOBAL_LIST_INIT(unrecommended_builds, list(
QDEL_NULL(tooltips)
QDEL_NULL(loot_panel)
QDEL_NULL(parallax_rock)
QDEL_LIST(parallax_layers_cached)
parallax_layers = null
seen_messages = null
Master.UpdateTickRate()
..() //Even though we're going to be hard deleted there are still some things that want to know the destroy is happening
+2 -1
View File
@@ -10,6 +10,7 @@
PARALLAX_HIGH,
PARALLAX_MED,
PARALLAX_LOW,
PARALLAX_BOOMER,
PARALLAX_DISABLE,
)
@@ -17,7 +18,7 @@
return PARALLAX_HIGH
/datum/preference/choiced/parallax/apply_to_client(client/client, value)
client.mob?.hud_used?.update_parallax_pref(client?.mob)
client.mob?.hud_used?.update_parallax_pref()
/datum/preference/choiced/parallax/deserialize(input, datum/preferences/preferences)
// Old preferences were numbers, which causes annoyances when