Gas overlay varied sprites

[SECBATON-GRIFFON]

[sprites]

2026-01-05.23-27-52.mp4

What this does

Allows gas overlays to pick from a set of overlays instead of just use one. Currently only used with frame offsets. (would be nice to be able to manipulate this directly on the icon but BYOND won't let me)

Why it's good

Less of each tile's gas overlay looking the exact same.

How it was tested

Opening a plasma, cryotheum and N2O canister in test_very_tiny while separating the room into two halves by windows, then breaking the windows, adding new tiles outside the room with manual building and buildmode, letting the gas drain.

Changelog

🆑

• imageadd: Gas overlays no longer look the same on every turf, now being varied a bit for plasma, cryotheum and N2O.

[gurfan]

How it was tested

Can you test scrubbing out the gases to see if the overlays are cleared properly?

[SonixApache]

image example...?

[CrazyAmphibian]

why not apply this to cryotheum, too?

[SECBATON-GRIFFON]

why not apply this to cryotheum, too?

i was thinking it wouldn't be as common in rounds, and it would've meant making 6 different icon states as a workaround for not being able to frame offset them, but if you insist

[west3436]

This is adding multiple overlays to each turf which is going to add up when we get a plasmaflood. Instead, why not look at how snow overlays work and use that approach? You can create 3 plasma vis masters in nullspace then just add them to the vis_contents of each turf

[SECBATON-GRIFFON]

This is adding multiple overlays to each turf which is going to add up when we get a plasmaflood. Instead, why not look at how snow overlays work and use that approach? You can create 3 plasma vis masters in nullspace then just add them to the vis_contents of each turf

it's using |= for the text stuff, which only adds unique values, plus i very specifically checked this so it wouldn't add multiple vis_contents. (NOT overlays) if it did, the results would be very obvious since the varied sprites are taken from pick() and would stack on each other fast, as it did earlier in testing before i fixed it.
proof, after a few update cycles:

[ghost]

gas doesnt have enough motion to account for the busy overlay image, this would look a lot better with a couple new sprites

[Eneocho]

You could also gain a lot of extra mileage by offsetting the "starting" time for the overlay, so they're unsync'd.

[SECBATON-GRIFFON]

You could also gain a lot of extra mileage by offsetting the "starting" time for the overlay, so they're unsync'd.

it felt bad enough to do it with sprite states already, i wish BYOND just had a way to offset them

[CrazyAmphibian]

according to @DeityLink, what you can do is give the gas overlay sprites directions, and have each direction be its own offset, then spawn the overlay with a random direction

[SECBATON-GRIFFON]

according to @DeityLink, what you can do is give the gas overlay sprites directions, and have each direction be its own offset, then spawn the overlay with a random direction

actually that is pretty efficient, but the end result would still be pick() ing an overlay to vis_contents

[SonixApache]

Test this again but make a 500x500 map to test it on.
And then test it with and without.

And, y'know, measure FPS / pay close attention to the profiler.

[DeityLink]

If I can give an opinion, those overlays should be completely replaced with particles. It'd look better AND use less CPU server side.

[west3436]

If I can give an opinion, those overlays should be completely replaced with particles. It'd look better AND use less CPU server side.

The server cost of displaying four icon states is FAR less than the client cost of spawning multiple particle sets per turf.

[Eneocho]

If I can give an opinion, those overlays should be completely replaced with particles. It'd look better AND use less CPU server side.

This would be true on any proper engine except ours, byond is a cesspool that we've gotten good at swimming through, but it's still a cesspool.

[DeityLink]

The server cost of displaying four icon states is FAR less than the client cost of spawning multiple particle sets per turf.

Except only turfs that are on your screen would matter anymore. Post-NarSie has rune particles on every space turfs and it works fine. So does the "holy fire"

[Eneocho]

That might be true, worth a test I guess.

[SECBATON-GRIFFON]

back in draft for some performance coding

[SECBATON-GRIFFON]

Test this again but make a 500x500 map to test it on. And then test it with and without.

And, y'know, measure FPS / pay close attention to the profiler.

had a look at the profiler, update_graphic() seems to only use 0.8 self cpu and then isn't called again after the gases get their sprites added. (done from adding plasma to all simturfs with SDQL, so this is an extreme case)

[Kurfursten]

To be clear, update_graphic is only called if necessary, not every tick, right? In that case, it's hard to imagine a performance impact at a significant level, even in very large rooms like atmos

[SECBATON-GRIFFON]

To be clear, update_graphic is only called if necessary, not every tick, right? In that case, it's hard to imagine a performance impact at a significant level, even in very large rooms like atmos

only when necessary it seems, as the profiler confirms (it doesn't show up at all on stop-refresh)

[Kurfursten]

In that case I see no serious concerns in this implementation. We can keep an eye on it.