ID:100199
 
Resolved
Applies to:DM Language
Status: Resolved

This issue has been resolved.
Atom.blend_mode would be a value specifying how the atom should be drawn to the screen. Valid values would be any constant allowed for the icon.Blend() proc's function parameter except ICON_UNDERLAY and ICON_OVERLAY. It would default to zero, which would keep behavior as it is now.

For example, a pixel colored #00F0 (or 0, 0, 1, 0) drawn on top of a white pixel using ICON_SUBTRACT would show up as yellow (#FFFF - #00F0 = #FF0F).

In order to allow multiplicative blending to lighten a pixel another constant may need to be added. The equation for drawing in this mode should be 2 * source color * destination color (if that's not clear, I'm talking about what is referred to as 2X Multiplicative Blending here). This way, blending white with navy blue (#008F) would result in pure blue since 2 * (1, 1, 1, 1) * (0, 0, 0, 0.5, 1) = (0, 0, 1, 1), while blending any color with gray would result in no change and blending a color with black would result in black.

These blend modes (especially together with custom shaders) would allow for cool lighting and particle effects as well as better-looking explosions. Being able to set the mode for each individual atom would allow a lot more flexibility than using icon.Blend() and would be a lot faster, since the effect should be rendered on the client's GPU as opposed to the server.
I don't know if it's possible to change blend modes on a per-icon basis or not. If it is, then it would indeed be interesting to allow for something like this, but I think it'd be difficult to manage in the software display.

However the existing Blend() types would not be applicable. ICON_ADD doesn't work as a simple addition, since it also goes with the lesser of the two opacities, and the same goes for ICON_SUBTRACT. I think repurposing the names for this would be inconsistent, and we'd end up getting "bug" reports from people claiming that ICON_ADD in Blend() didn't work the exact same way as in atom blending.

[edit]
It does appear changing blend modes is possible. However from what I'm seeing there's no such thing as a subtractive mode. You basically just have additive, multiplicative, overlays, and a bunch of essentially useless ones.
It seems weird that you can't get subtractive blending, as XNA allows for very detailed control over the blending and it's written on top of DirectX (which I assume is what BYOND uses, although I think I found that OpenGL also supports subtractive blending).

When hardware acceleration is turned off, you'd probably have to hide any atoms that aren't set to the default blending mode.
This really needs to be a thing, specially for lighting systems
@ Tobba: I'm not sure. This wouldn't really make anything faster for lighting systems, but this could potentially make things a little prettier.

I love the idea of this feature but I would prefer to see some actual games on the site so that the feature, if implemented, won't get forgotten and unused.
LordAndrew resolved issue