G2 - Colors - How many decimals?

I’m in the process of converting an old app. I noted that I can put /255 next to each instance of color data but I’m worried about so many additional division operation that will happen over & over. Am I fussing over nothing?

Just to make sure I don’t waste any processor cycles I am prepared to do my divisions and put the resulting 0 to 1 decimal in there. Question is how many decimal points should I round to in order to get the exact match. Anyone know? 

Thanks much.

I guess 0.00392 is enough for multiplier. It gives 0.9996 for 255 so probably close enough.

The tip about the /255 was posted in the forum by someone with Corona, so I am guessing it’s okay to use like that.  I would consider using a custom function to assign colors so that you can change the formula globally if the need ever arises.

[lua]color = function(r,g,b) return (r/255), (g/255), (b/255); end[/lua]

Used like so:

[lua]txtObj:setFillColor( color( 128, 128, 128 ) )[/lua]

Usefull, but question was about not using division. Generally with present CPUs it’s rather not significant performance improvement but always.

And probobably using division directly (txtObj:setFillColor(128/255, 100/255, 0/255)) is not bad at all as value in range (0~1) is, highly probable, calculated at compilation time not runtime. 

Also you can calculate 1/255 once and multiply your color (0~255) by it.

Using function as suggested by @develephant will always result in generating function calls (executed at runtime) with division operations in compiled code so the outcome will be calling this every time you want to set constant values for color (if values are dynamic this scenario is ok).

This is interesting. I did not know this could be the case. If so then I should not worry and keep using the /255 approach. Can someone from Corona Labs kindly confirm whether these divisions occur at compile time or runtime? Thanks

Rule is, if something doesn’t affect performance then there is no need to bother.
Just speaking generally, searching everywhere for performance improvements can be aimless effeort (premature optimization). Sometimes it doesn’t matter if something takes longer, if hardware is capable handling this at unnoticeable time - code structure is in such cases better tradeoff :slight_smile:
As such, @develephant solution is great - it’s simple and clear and easily maintainable, with just a bit of unnoticeable overhead :smiley:

I guess 0.00392 is enough for multiplier. It gives 0.9996 for 255 so probably close enough.

The tip about the /255 was posted in the forum by someone with Corona, so I am guessing it’s okay to use like that.  I would consider using a custom function to assign colors so that you can change the formula globally if the need ever arises.

[lua]color = function(r,g,b) return (r/255), (g/255), (b/255); end[/lua]

Used like so:

[lua]txtObj:setFillColor( color( 128, 128, 128 ) )[/lua]

Usefull, but question was about not using division. Generally with present CPUs it’s rather not significant performance improvement but always.

And probobably using division directly (txtObj:setFillColor(128/255, 100/255, 0/255)) is not bad at all as value in range (0~1) is, highly probable, calculated at compilation time not runtime. 

Also you can calculate 1/255 once and multiply your color (0~255) by it.

Using function as suggested by @develephant will always result in generating function calls (executed at runtime) with division operations in compiled code so the outcome will be calling this every time you want to set constant values for color (if values are dynamic this scenario is ok).

This is interesting. I did not know this could be the case. If so then I should not worry and keep using the /255 approach. Can someone from Corona Labs kindly confirm whether these divisions occur at compile time or runtime? Thanks

Rule is, if something doesn’t affect performance then there is no need to bother.
Just speaking generally, searching everywhere for performance improvements can be aimless effeort (premature optimization). Sometimes it doesn’t matter if something takes longer, if hardware is capable handling this at unnoticeable time - code structure is in such cases better tradeoff :slight_smile:
As such, @develephant solution is great - it’s simple and clear and easily maintainable, with just a bit of unnoticeable overhead :smiley: