I have just done a test to update my blendmode table, and noticed a regression in canvas: SUBTRACT doesn’t work anymore.
The current state for the “main” blendmodes is
ADD YES YES
ALPHA NO YES
DARKEN NO YES
DIFFERENCE NO YES
ERASE NO YES
HARDLIGHT NO YES
INVERT NO NO
LAYER NO NO
LIGHTEN NO YES
MULTIPLY YES YES
OVERLAY NO YES
SCREEN YES YES
SUBTRACT YES NO
I don’t know when this regression has been introduced, I created the table ages ago.
It does not appear to be implemented, do you know of a canvas blend mode it should use?
“subtract” … doesn’t work
I don’t know how to access the CanvasRenderingContext2D js to see the existing strings
Here’s a list of supported modes in canvas:
I don’t think there’s a SUBTRACT mode, you said that it used to work, I wonder what version that was, and what was being used?
No, it is not in the list, the result should be this one (in Photoshop)
Maybe it will be possible with a shader by SHADER blendmode.
Openfl should strictly reproduce AS3 features, but is there a plan to extend them i.e. supporting all other possible blendmodes avoiding to add other framework (like i.e. Flixel) upon Openfl?
Which ones do we not support? Which ones could we support in OpenGL?
It’s a bit tricky because Cairo/canvas, Flash and GL blend modes don’t all overlap
The combinations in the link above are 25(ignoring “source-over”), while the AS3 Blendmodes are 12 (ignoring NORMAL, LAYER and SHADER), and not all overlapping, so the possible additional blendmodes could be a significant number, obviously considering the differences between Canvas, GL etc, that are already pretty evident.
I’d like to know how many developers are still using Flash/AIR.
Perhaps we could allow some form of custom blend modes, since the abstract is fundamentally a string or a number, we could form some way of allowing arbitrary strings for canvas/cairo or maybe integer types for GL (though in GL’s case, we have a combination of two to four values for blending, so that’s more tricky)
BlendMode.XXX if you want to stay with the standard ones (and hope they work in the current target), otherwise target-specific ones, like BlendModeGL.XXX for WebGL, BlendModeCanvas.XXX for Canvas etc, that will fall back to the standard ones if available, or to the default one (NORMAL) if not supported by the current target.
With this approach the default class BlendMode would stay untouched, while the parallel target-specific classes could grow up, keeping fall back safety.
But this means adding new features to the AS3 base: is it right to stay faithful to AS3 or Openfl will eventually go on and grow up?
Creating target-specific expansions would be really cool, sometimes necessary to be free from other platforms restrictions.