Blend modes have been requested numerous times, however, it would also be very useful to have a value that all color values are multiplied with before blending, this should be able to go above 1 and would help greatly with lighting systems
(color values going outside of normal scale only makes sense with multiplicative blending though)
Last time this was requested there was talk about that it would be a little inconsistent and that all Blend() modes are not possible, I dont think this really matters too much though as its place is within special effects and wont be used all over, but it will add a very great deal of prettiness without speed implications
ID:1324730
 Jul 15 2013, 2:23 am
|
|||||||
Resolved
| |||||||
I dont see too much use in additive blending modes though, multiplicative blending would be the most useful I think
| |
Additive blending at least gets you special effects like explosions. Multiplicative does provide for nice lighting effects, but it's not feasible in GDI.
| |
Why is software rendering still a thing though, wouldent it make more sense to dump it and stop the hardware renderer from constantly dying in a fire?
| |
I dont see how transforms would work in GDI anyways
| |
Transforms in GDI work through the magic of PlgBlt().
| |
Multiplicative would definitely be the most useful thing I could see, but if that's not feasible, well, it's still something I've been wanting for a long time. Does GDI support XOR drawing modes at all?
| |
I'm still curious why the GDI renderer is still used though, DirectX should fall back to software, so I dont see how it could ever fail
| |
I'm going to go ahead with a color multiplier, and I'd also like to make other blend modes available. The color mask, and most of the new blend modes, would be hardware-mode only. However, I'd like to get some feedback on implementation.
I was thinking of atom.color and atom.blend_mode as the new var names. Originally I thought I might just fold atom.alpha into atom.color but then I realized 1) it's more useful as a separate var for easy access, and 2) setting color="#0000" or color=null might be bad on animation. So I'm thinking color will only set alpha if an alpha component has been included. For blend modes, I can see these being useful, but what else? Normal Additive Multiplicative (hardware-only) Doing a full gamut of possible blend modes seems silly if only a few would ever be used, and KISS is the approach I'd most like to take here. | |
Normal should default to OVERLAY, correct?
Just going off what's available in Photoshop's blending modes: Add Sub Mul Div Overlay Screen Hard_Mix Soft_Mix Vivid_Mix Lighter Darker Burn Dodge XOR AND NOT There's a bunch of others, but honestly, these are the ones I tend to use when generating textures for 3D models in photoshop most often. | |
The question of the hour, though, is which of these blend modes are relevant to BYOND games. Doing image editing in a BYOND game would of course be silly, so for me it's a question of what we really need.
DirectX allows for these blending factors on either source (overlay) or destination (underlay): Zero One Source color Inverse source color Source alpha Inverse source alpha Destination color Inverse destination color Destination alpha Inverse destination alpha There are others but I don't see them being useful, let alone always available. It also allows these modes: Add: src + dst Subtract: src - dst Reverse Subtract: dst - src Min: min(src,dst) Max: max(src,dst) This is what we would have for the following modes, with the blend types listed in Src, Dst, Op order: Overlay: Src Alpha, Inv Src Alpha, Add Additive: Src Alpha, One, Add Subtractive: Src Alpha, Inv Src Alpha, Rev Sub Min: Src Alpha, One, Min Max: Src Alpha, One, Max Multiplicative blending turns out to be moderately iffy, as this would seem legit: Multiply: Zero, Src Color, Add The only problem might be that I'm not sure the value would be correct where src.alpha is less than 255. There are ways to deal with that with a little preprocessing (namely, overlaying the pixels over solid white before creating the sprite), which perhaps isn't the best solution but is relatively simple. Most of Photoshop's blend modes require some operations that DirectX can't do though. If you look at this list, you'll notice most of those formulas don't fit into the parameters defined above. Screen, and many other blend modes based on it, is out of the question. But since this all comes down to what's actually useful to games, I'm hard-pressed to think of anything outside of lighting (multiplicative) and explosions (additive). | |
I mostly see use in multiplicative and additive, but subtractive should probably be included for completeness, min/max could be useful for some kind of special effects
| |
For multiplicative rendering of one pixel (src) over another (dst), I would use it as follows (assuming it's feasible)
FinalPixel = (Multiply(Src.RGB, Dst.RGB) * Src.A) + (Dst.RGB * (255 - Src.A)) Essentially, an Alpha of 255 means straight-multiply, and an Alpha of 0 would be Waste-Cycles. A separate type of multiply, where the operation acts as if Src.A were always 255, and then sets the Final.A = Src.A would be useful as well. This would give us the following: * Overlay (Currently the only op we have) * Additive * Subtractive * Multiply-Preserve (Alpha) * Multiply-Overwrite (Alpha) | |
In my opinion, I would only make use of Additive, Subtractive, and Multiply.
The way multiply would work is that the pixels in the backbuffer would be multiplied by the pixels in the icon as a percentile. R, G, B, and A are the new RGBA values of a pixel. PR, PG, PB, and PA are the icon's current pixel. R = R * (PR / 255) G = G * (PG / 255) B = B * (PB / 255) A = A * (PA / 255) For example, a yellow background is multiplied with a green icon: R = 255 * (0 / 255) G = 255 * (255 / 255) B = 0 * (0 / 255) The result is green, so not much change there. But what if we wanted to make that icon blue? R = 255 * (0/255) G = 255 * (0/255) B = 0 * (255/255) we get black! Edit: At least this is the way it works in Paint.NET | |
Lummox JR resolved issue with message:
atom.blend_mode has been added, which will allow users to switch to additive, subtractive, and multiplicative blending for icons. Overlays can have a different blend mode than the main icon if desired. This feature appears in hardware rendering mode only. | |
HOORAY!
Does this allow masking by blending an alpha-multiplier over something? | |
The question I bring up is: Given that standard "overlay" alpha blending and additive blending are feasible, how would we want to represent this in a var? I don't know if other blend modes would ever be achievable, but something expandable probably isn't a bad idea.