Skip to content
Forum Archive

Suggestion: custom blend mode

7 posts

fragmer#

Suggestion: custom blend mode

I want custom blend mode!!! 😁
How about once more option in the "Blend mode" dropdown menu, and a textfield:
blend mode: [custom]V]

(blablabla)
two variables: in and out.
Here's this syntax applied to existing modes:
ignore:       out

replace:      in

50/50:        in*.5+out*.5

maximum:      max(in,out)

additive:     in+out

sub1:         out-in

sub2:         in-out

multiply:     in*out

minimum:      min(in,out)
I suggest the whole thing being static, i.e. calculated once, otherwise may get too slow :P
XOR is unavalible - until AVS has a function or it.
Every other pixel and every other line can be done but it's pretty complex and slow :P.
Adjustable will be only useful if this thing will be dynamicly calculated (not static).
Also separate formulas for each channel (RGB) can be optional 🙂
I think this will help a lot to do such things as gradient overlays [in*x+out*(1-x)]; color tricks and frames. Well, maybe not. What does the community think?
TomyLobo#
it would be nice if additional blend modes could be inserted by APEs. this would have the required speed for dealing with each pixel seperately.
UnConeD#
fragmer: I don't really see this happening. The only reason blend modes are so fast is because they are coded in optimized MMX instructions.

Using the current evallib for this, on e.g. a 320x240 preset, would mean doing the equivalent of a 76800 point superscope.

A special version of evallib would have to be made which can compile to these instructions and which can process packed 24-bit colors (remember, evallib is only floating point). Because it would have to be dynamic, common optimizations and tricks would probably not be implemented, resulting in globally slower behaviour.

In other words: nope.
fragmer#
what a pleasure to listen to a speech of an educated person 🙂 Thanks for enlighting, UCD. I thought static custom blend modes would be not much slower then cutom movements...