How do I dynamically color sprites

http://brandontreb.com/cocos2d-tutorial-dynamically-coloring-sprites

After reading this brief tutorial I was wondering if something like this is possible with Construct 2? And more specifically, has anyone accomplished it? I have my doubts but I thought I'd ask anyway as someone usually comes up with something new eventually!

I thought about it a bit trying to use webgl effects and using the setColor but I don't think it's as precise because it colors the sprite as a whole, so the skin tone would be lost unless you separate the body from the head and attach a unique head to body. The problem with that is now there are two sprites for every one sprite that you would have had, if you created them all individually. The same goes for say, attaching accessories such as hats,glasses, and hairstyles. so I'm not sure how that would effect runtime in the long run.

Edit: One would have to build each character as 6 different sprites and have them color randomly. but how would this effect runtime with for example 400 characters made up of 5 or six sprites each?

In short does anyone have a creative suggestion for creating several animated, unique humanoid sprites such as in the example of "Bitizens" for the purpose of saving resources? Is it even practical? The alternative being that each unique sprite is drawn and brought into the game as it's own sprite rather than creating them on the fly.

Very good question. I wonder if using the hue effect could make it work. Will try when I get home and get back to you.

I too came across that very question. As an example lets say you have a platformer and you can collect coins. I would want to use the least amount of memory possible so I would have an animated coins (say 5 frames) rendered in grey scale and would just apply HSL to get my Platinum, Gold, Silver and Copper. I end up with 4 rotating coins with increasing my memory footprint except for the engine code to handle such.

I don't think it's possible as such, but you can make x frames and select different ones for your sprite. If you need the sprite to also be animated, then replace the entire sprite with another one with a different color, which spawns at the same coordinate while the original is destroyed. It's not a pretty solution, but it's a workaround...

You're not dynamically colouring sprites then, you're changing animations / frames, which is completely different.

I'm playing with it now using setColor but it's very limiting because RGB only goes from 0 to 100.

Edit: actually set color recolors the entire sprite regardless of shading so it's not useful

No 255?

It looks like the effect "Replace Color" might be the way to go, it seems to include 255

Regarding performance i think the manual discourages this entire practice

[quote:qhqeaak2]Performance

Using too many effects can cause poor performance, especially on mobile devices. Try to only use effects when it is important to the appearance of the game.

Creating many instances of an object using effects can be very inefficient, since the effect must be processed repeatedly for small areas. If many instances need to use an effect, often it is more efficient to place all the instances on their own layer, and apply the effect to that layer instead. This can improve performance whilst producing the same visual appearance.

Never use effects to process a static effect on an object. For example, do not use the 'Grayscale' effect to make an object always appear grayscale. Instead apply the grayscale effect in an image editor and import a grayscale image to the object, without using any effects. This has the same visual result, and avoids performance-degrading effect processing. Effects like 'Grayscale' should only be used for transitions or making objects only occasionally appear grayscale.

For more information, see the manual section on performance tips.

It's not very clear to me, what it means by 'using too many effects. Whether that is too many different effects or too many objects with an effect applied to it. Thoughts?

It just means that in C2's case, it's better to actually make and import the same sprite in different colours than to use the effect to change it "in-engine"... Which is a shame!

How is 0-100 limiting? Just convert a 0-255 value to 0-100 with value/255*100.

Some time back I was tinkering with a custom character maker and needed to do the same thing as you when trying to dynamical change color. Here is my solution, One make a gray scale sprite that will be your base as starting with a colored sprite will make tuning the HSL difficult. Next make a variable called ColorTyp set to zero and also add the Adjust HSL Effect to your sprite.

In your events make a every tick block and place a number of sub branch's below that. Using the system compare pram set it for if ColorType=0, =1, =2 etc. the actions of each of those branch's you will use the "set effect "AdjustHSL" pram 0 to (Number)" repeat for pram 1 and 2.

Having done that and adjusted the 3 parameters for the sprites HSL effect all you have to then do is change that ColorTyp var to dynamically change the sprite.

But again you would have to do this on a sprite by sprite bases but have you looked into containers? if you put all the sprites into a container that should cut down of the cost of having all these sprites

<><><>example

Every Tick | ___________

ColorTyp=0 | Effect Adjust HSL param 0 to 50| Effect Adjust HSL param 1 to 50| Effect Adjust HSL param 2 to 50

ColorTyp=1 | Effect Adjust HSL param 0 to 10| Effect Adjust HSL param 1 to 75| Effect Adjust HSL param 2 to 50

ColorTyp=2 | Effect Adjust HSL param 0 to 100| Effect Adjust HSL param 1 to 25| Effect Adjust HSL param 2 to 80

I disagree. the example that I used with the five frame coin is just that one example. What if somebody in here was writing the next World of Warcraft. When you start thinking of backpacks potions armor horses whatever it's a lot easier to render the sprite in parts and in grayscale and then apply a color filter then you have a smaller footprint but it also allows you to have a lot more possibilities visually.

this really should be a feature request. I'm actually kind of surprised considering how will the c2 engine is designed. it should be added to the image class. C2 is an awesome engine there's no reason to limit it.

I achieved the desired effect using WebGL replaceColor. But no one has had any insight as to whether this is a practical for mobile devices or not. Namely because so many sprites would be using webGL, + it adds 5+ sprites per character which could be made up of one single sprite (just more of them)

CrazyVulcan

Every character would be made up of about 5+ sprites, are you suggesting containers merge them together somehow into a single object to save space? Also I'm watching your random character generation post, I hope you figure it out as it also interests me.