Are color filters like CC had on the todo list?

I've been experimenting with the tint effect in C2 and found it to be terribly slow in comparison to CC's color filter, which appears to have no performance impact at all. Like can't even have 100 tinted sprites on the screen at 60 fps slow, whereas CC can manage 10,000 color filtered sprites, the exact same number of which it can manage with no filter.

I found a post that claims they are possible: http://www.scirra.com/forum/forum_posts.asp?TID=62645&PID=385150&SID=aca5bf8c-1187-ab8c9fea-41435-9788078704&title=cc-c2-discussion#385150

So I'm wondering if they are in fact on the todo list. I really liked them in CC.

We don't have plans to make a built-in color filter, because it's not supported in canvas2D. Since it's only supported in WebGL, the tint shader is the best way to do it. As with all shaders, it's very inefficient to have large numbers of instances all using shaders - the much more efficient way to do it is apply the effect to a layer, then place all those instances on that layer.

Ashley - But that won't work because I need the instances to all be different colors, and in some cases shifting different colors dynamically.

Also, I'm afraid I don't understand your reasoning. You say you have no plans to make a color filter because it requires webgl, so I should use a shader instead - but shaders also require webgl, and they were implemented, as was the tint shader itself, which produces the same visual effect, but with an utterly colossal performance hit (less than a 100th of the speed!). Why can't the color filter simply be another feature that requires webgl? For those of us deploying only to webgl enabled platforms like node webkit and cocoonjs, canvas2D not supporting them doesn't matter (and people deploying to the web have the option of detecting canvas2d and doing something else already, same as with shaders).

Could, for example, the color filer be implemented, but listed as a shader, and used in the same way as one? Then it would be clear that it requires webgl the same way shaders do, and could theoretically plug in to the ACEs and shader list that's already there.

This would make a huge difference in my projects. For example, when designing levels it can add a lot more customization to the look of the level elements, and having them makes the difference between if a painting program I want to make is even possible or not (I can't make it in CC either because of some bugs in the image manipulator that never got fixed). Please reconsider!

+1

I wasn't aware that the tint effect would impact performance, was experimenting with it recently as I will need something to colourise sprites uniquely. Rather not nerf performance <img src="smileys/smiley31.gif" border="0" align="middle" />

It's a feature I've been missing too in many projects. Would be great to have an efficient solution for recoloring sprites, as it's something I find myself needing on many occasions.

I feel that even if it's webGL only, for minor features like this as long as the user knows it's WebGL only I see no harm.

Hmm... I'll look in to it. I'm also a little worried it will affect overall performance (it might mean sending a color with every sprite, even if they don't use filters), but maybe it can be done efficiently anyway.

Awesome, thanks Ashley!

Looking forward to this feature! I loved the filters in CC, easy way to add color variety to existing sprites.

[quote:3u2ngezv]"I wasn't aware that the tint effect would impact performance"

Anything can affect performance ; whilst tools like C2 are quite high-level, in terms of abstraction, understanding how it works internally can be useful to explain why things are the way they are.

Basically, by having unique sets of shader attributes per instance, you prevent the system from batching similar objects. The hardware is very efficient at processing large amount of identical data ; the more you make the data unique, the more the objects have to be broken down into smaller groups, each generating drawcalls with specific render settings and shader parameters.

It's much faster to render 10.000 triangles with the same attributes than 1000 triangles with unique attributes ; in the second case, you spend most of your CPU/GPU time in the pre-render stages and the driver overhead.

There's always a trade-off between CPU/GPU time and memory/video memory, and a balance to find between these. If you don't need to dynamically colour sprites, just bake predefined colours into texture atlases ; you'll burn a bit of memory, but the geometry will be quick to process.

There isn't a universally "better" way of doing this, it all depends on the application and the external requirements.