xyhur — a name the Season Ledger will remember — handed me the kind of bug report I genuinely love: during the Corporate Ladder's Quarterly Earnings Call — the moment PROVIDENCE interrupts your shift to announce that the numbers have been reviewed, and so have you — the entire screen flashed acid green. Not the thin pulsing border at the edges that I built. The whole thing. Wall to wall, corner to corner, one solid wash of green, like the station had been dipped in antifreeze. Then it faded and the shift carried on as if nothing had happened.
This is the story of why, because the answer turned out to be one of my favorite classes of bug: code that was wrong from the day it was written and never once got caught, because nothing had ever actually run it.
What was supposed to happen
SOLREIGN has a shared screen-effect channel: a handful of station events raise one network event, the client puts up an overlay, and the overlay drives a little fragment shader, acid_screen_border.swsl. The shader computes each pixel's distance to the nearest screen edge and, if that distance is inside the border thickness (30 pixels, from the prototype YAML), paints it acid green with an alpha that fades toward the interior and pulses on a sine of time. Everything farther in than 30 pixels is supposed to stay transparent. A polite corporate heartbeat around the rim of your vision. That's it.
The earnings call is one of six things that fires it — solar flares, the opening sting of an acid storm, a couple of station directives, and some ceremonial moments use the same channel. Same overlay, same shader, same border.
The hunt
My first theory was the obvious one: some caller is passing an oversized border. If one event asks for a 600-pixel border on a 1080-pixel-tall screen, "border" and "entire screen" are the same thing.
That theory died fast, because there is nothing to pass. Every one of the six call sites shares a single shader prototype with a single fixed borderSize: 30.0. The only per-caller knob is duration, and duration was already clamped to a sane range at construction. No caller was doing anything wrong. Which is the moment a bug hunt gets interesting, because if no caller is wrong and the symptom is real, the mechanism itself is broken — and it's broken for all six callers, and has been the whole time.
The root cause
Here's the part that's useful if you build on RobustToolbox.
An .swsl file is not a complete shader. The engine compiles your fragment() function into a surrounding template, and which template depends on a preset declaration at the top of your file. If you write light_mode unshaded; or preset raw;, you get one of the specialized templates. If you write neither — and this shader wrote neither — you silently get ShaderPreset.Default, the engine's base-default.frag.
That default template does three things that matter here. It declares a local lowp vec4 COLOR; and never initializes it. It samples the light map into LIGHT — a real sample of the world's lighting, unless the shader is unshaded, in which case the engine neutralizes it to vec4(1.0) (it signals this to the template by smuggling a negative vertex modulate through and decoding it as MODULATE = -1.0 - VtxModulate). And its final line unconditionally multiplies COLOR by MODULATE and LIGHT and writes the result to gl_FragColor — for every fragment, whether or not your code ever touched COLOR.
So there is an unwritten contract: your fragment() must assign COLOR on every code path, because the template is going to use it either way.
Our shader only assigned COLOR inside the border check. At 1920x1080 with a 30-pixel border, over 90% of the screen's pixels take the other path. Every one of those fragments fed an uninitialized local into that final multiply. That is undefined behavior — GLSL makes no promise about what an uninitialized local reads as. It could read as zero on one driver and garbage on the next. On xyhur's hardware it read as something decidedly non-zero and green-tinted, and because the shader wasn't unshaded, LIGHT was live lighting data rather than vec4(1.0), so the garbage got modulated by the station's actual light map on its way to the screen.
Sit with what that means: the border was never too big. The border was the only part of the shader that worked. It was the other 90% of the screen — the pixels whose entire job was to stay transparent — rendering noise that happened to look like the border color.
Why nothing ever caught it
This shader is adapted from an upstream one, colored_screen_border.swsl, which backs upstream's ColoredScreenBorderOverlay. That upstream shader has the exact same bug — no light mode, COLOR only assigned inside the conditional. Nobody upstream ever saw it, because that overlay is dead code: it's never added to any viewport. Our Quarterly Earnings Call is, as far as I can tell, the first time anything in this shader's entire lineage ran in front of a live player.
Meanwhile, every shader in the codebase that legitimately covers the full screen — nightvision, hologram, stealth, cooldown — does both things correctly: declares light_mode unshaded; and assigns COLOR unconditionally on every fragment. The broken one was the one that got copied from something that had never been called. "It came from upstream" and "it has been battle-tested" are different claims, and the gap between them is exactly the size of this bug.
The fix
Two lines, then two backstops.
The actual fix is the first line of fragment() now: COLOR = vec4(0.0); — explicit, unconditional, transparent everywhere until the border check proves otherwise. That removes the undefined-behavior read entirely, on every driver, forever. A transparent zero multiplied by any MODULATE and any LIGHT is still transparent.
Alongside it, the shader now declares light_mode unshaded;. A screen-edge accent should not be tinted by whether you're standing in a dark corridor — it's UI-adjacent, not a lit sprite. Worth being honest about the ordering here: unshaded alone would not have fixed this. An uninitialized read is broken whether or not the garbage gets multiplied by lighting afterwards. COLOR = vec4(0.0) is the fix; unshaded is correctness beside it.
Then, because "the mechanism was broken for every caller" is the kind of sentence I don't want to write twice:
- The overlay now clamps border thickness against the live viewport every frame, capping it at 9% of the smaller screen dimension — so no future prototype, re-theme, or caller can push edge coverage past roughly a third of the screen, no matter what it asks for. (Fun wrinkle: the overlay had been using the shared cached shader instance, which is immutable — setting a parameter on it per-frame isn't even legal. It now duplicates a unique instance. The clamp math has its own tests sweeping viewport shapes from 2560x1440 down to portrait-phone dimensions.)
- There's now a reduced-motion exemption. A pulsing screen-edge flash is precisely the category of thing the
accessibility.reduced_motionsetting exists to suppress, and this system predated the check. Clients with reduced motion on now skip the event entirely.
What it teaches
If you write shaders for SS14, the transferable lessons are these. An .swsl with no preset declaration gets base-default.frag silently, and that template does not initialize COLOR — so assign COLOR on every code path, first line if you can. Screen-space overlay shaders almost always want light_mode unshaded;, or your UI effect inherits the mood lighting. And it's worth grepping your shader folder for files that neither declare a light mode nor unconditionally assign COLOR — that combination is a loaded gun that goes off the first time a live caller picks it up. Mine waited until an earnings call.
PROVIDENCE has logged the incident, and the Ledger credits xyhur with its discovery — if your screen ever does something it shouldn't, report it; you'll end up in a post like this one. The next Quarterly Earnings Call will pulse politely at the edges of your screen, where it belongs. Attendance remains mandatory.
— See you on shift.