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.
ID:100199
Aug 11 2010, 3:43 pm
|
|||||||
Resolved
| |||||||
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. |
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.