Hello,
I know there have been a number of people who have asked are the following possible...
retro palette cycling?
palette swaps?
dirty lens / camera + dynamic bloom?
...And the answer is no, not in the way it would be best to do so, at any rate. I have been working on some shaders that would enable retro palette effects, and mutiple texture shaders like dirty lens plus bloom. I have a few other ideas. These can be implemented in Unity for example without problem, but not construct because...
...There is just one technical problem: In a construct 2 effects file you can only reference 2 textures. The one being drawn and where it is being drawn to. Thats it: front and back.
A huge part of making cool filters and effects (especially non process intensive ones - which is key for construct 2 performance) is to reference other premade textures. Old school film effects, complex film grain, and other camera effects can be found using no additional textures, but they have to compute the noise and patterns they create. some effects just can't be done without additional textures (like palette cycling, and image based filters) without some form of compromise that usually affects performance. Some can't be done period.
The solution is simple. Stupid simple as a matter of fact.
All that is needed is for the effects portion of a plugin (where you add effects to a plugin or layer) to include another field where you can load an image (the ability to add more than one would be nice, but not needed as you could combine multiple into one ) and attach it specifically to the effect. Within the effect file you could then reference the image as....
uniform lowp sampler2D samplerCustom1;
uniform lowp sampler2d samplerCustom2;
...in addition to samplerfront and samplerback.
This means you could have the ability to make super awesome palette swapping filters, dynamic scratched lens filters with hdr bloom, professional color Luts with dynamic blending between different lighting schemes, and much much more all at a reasonable performance cost.
As I said, this should be easy to add, but it needs to be officially supported. Ashley likes to give priority to things that are a.) actually needed and b.) desired by the community. I think I have given a good case for why it is needed, and I believe it should take little time to implement (easy to solve with high value).
What about Ashley? I would love to be able to develop some of these shaders but I need to be able to reference at least 1 additional texture in an effects file (samplercustom). Just a few lines of code here and there and presto! It would be totally worth it. o.o
On a side note, it would be possible, though highly complicated, impractical, and downright silly, to include the texture needed combined with the sprite being effected, you could then vtex to correctly look at the actual sprite vs the texture packaged with it. The problem is that animated sprites would become massive as each frame would have to include the texture (some of which would likely be at least 256,256. Then each effect would have stringent use case possibilities which sucks for modularity... I think you get the point.