Apparent problem with colors about tween.lua

[kikito]

Hi norealname!

You have written quite a lot! Let me answer point by point

1. There appears to be some linkage between changing colors in one event and another event. The order of events is critical to obtain the assign color.

The only scenario where I can see this happening is when you use the same variable for two different sources. Example:

local red = {255,0,0}

local foo = { color = red }
tween(1, foo, { ... })

local bar = { color = red }
tween(1, bar, { ... })

The problem on the code above is that both foo and bar store a reference to the same table - in this case red. The tweens are being told to "fight" against each other in order to change the same variable. This will not happen if you simply specify {255, 0,0} in both cases:

local foo = { color = {255,0,0} }
tween(1, foo, { ... })

local bar = { color = {255,0,0} }
tween(1, bar, { ... })

This makes two separate tables for the color, so there's no "linkage". Another option would be using a table that clones tables:

local function copy(t)
  local other = {}
  for i=1, #t do other[i] = t[i] end
  return other
end

local red = {255, 0,0}

local foo = { color = copy(red) }
tween(1, foo, { ... })

local bar = { color = copy(red) }
tween(1, bar, { ... })

Of course, there's lots of room for variance here - let me know if the point wasn't clear enough.

1. Some of the colors returned are less than zero. This doesn't seem to be a problem with 2DLove but Lua won't accept.
   I had to add checks like if r < 0 then r = 0 end etc. Not all 'easings' seem to produce these errors.

Indeed. back, bounce and elastic functions will tween the values slightly "above and below" the limits. This is their expected behavior. I can't add the checks you suggest because in that case the "positions" will not look "bouncy".

If you want to use back, bounce or elastic easings for tweening colors, then the simples solution be to add some "safety space". Instead of going from "full red" (255,0,0) to "full white" (255,255,255) use something less extreme, like (220, 20, 20) for red and (220, 220, 220). For white. This way the "bounciness" will be contained within those limits. Then you can do a quick tween using linear interpolation to the extreme colors.

Or, you can provide your own tweening function. You actually don't need to modify the library. Instead, if you give it an easing function on the 4rth parameter, tween will use it.

Another topic - text seems to be handled differently than other objects:

Indeed. Tweening is only done with numbers. No text.

1. Can't get tween.reset followed by a function call to text() to restart. Have to reload all the text settings.

I'm sorry, I don't understand this. Can you produce a .love file illustrating this issue you are having?

1. Can't change text="something" to change text as text moves aroung screen.

Are you looking for a gradual change, or do you just want the text to change at a given time? In the first case, sorry, but that's not supported.
I don't think I'll be able to implement interpolation between strings. I don't have a lot of time, and it seems like something that not a lot of people will use.

If you just want the text to change from one value to another after some time, you can use the callback parameter to change the text:

local message = { x = 0, y = 0, text = 'hello!' }

tween(3,message, {x=300, y=300}, 'linear', function() message.text = 'bye!' end)

If you need to change the text more often than that, I recommend you to give a look to my other library, cron.lua. It will allow you to change the text more easily.

1. The same code produces different color transitions for the text when using Love and Lua.

This is probably not related with the text itself, but with the "linkage problem" that you mentioned before (point 1). Applying any of the solutions I mentioned should solve this.

Sure would be nice to have some documentation in 'tween' to help find out what's going on.

I'm sorry you didn't find the documentation satisfying enough. I did as much as I could, but unfortunately my time was limited. What, exactly, do you think is missing?

Nice effects but struggling to control.

I hope this post helps you on that.

I'll leave this issue closed for now. If you need further assistance, please let me know here and I'll re-open (I'm not sure you will have permission to re-open it yourself, if yes, please do so if you need to)

Regards!

[norealname]

Hi kikito!
Answers are very helpful.
Think I've got enough to go it alone now.
Thanks!
Best,
norealname

---

From: "kikito"
[email protected]
Sent: Friday, May 13, 2011 5:18 PM
To: [email protected]
Subject: Re: [tween.lua] Apparent problem with colors (#3)

Hi norealname!

You have written quite a lot! Let me answer point by point

1. There appears to be some linkage between changing colors in one event
   and another event. The order of events is critical to obtain the assign
   color.

The only scenario where I can see this happening is when you use the same
variable for two different sources. Example:

local red = {255,0,0}

local foo = { color = red }
tween(1, foo, { ... })

local bar = { color = red }
tween(1, bar, { ... })

The problem on the code above is that both foo and bar store a reference
to the same table - in this case red. The tweens are being told to "fight"
against each other in order to change the same variable. This will not
happen if you simply specify {255, 0,0} in both cases:

local foo = { color = {255,0,0} }
tween(1, foo, { ... })

local bar = { color = {255,0,0} }
tween(1, bar, { ... })

This makes two separate tables for the color, so there's no "linkage".
Another option would be using a table that clones tables:

local function copy(t)
 local other = {}
 for i=1, #t do other[i] = t[i] end
 return other
end

local red = {255, 0,0}

local foo = { color = copy(red) }
tween(1, foo, { ... })

local bar = { color = copy(red) }
tween(1, bar, { ... })

Of course, there's lots of room for variance here - let me know if the
point wasn't clear enough.

1. Some of the colors returned are less than zero. This doesn't seem to be
   a problem with 2DLove but Lua won't accept.
   I had to add checks like if r < 0 then r = 0 end etc. Not all 'easings'
   seem to produce these errors.

Indeed. back, bounce and elastic functions will tween the values slightly
"above and below" the limits. This is their expected behavior. I can't add
the checks you suggest because in that case the "positions" will not look
"bouncy".

If you want to use back, bounce or elastic easings for tweening colors,
then the simples solution be to add some "safety space". Instead of going
from "full red" (255,0,0) to "full white" (255,255,255) use something less
extreme, like (220, 20, 20) for red and (220, 220, 220). For white. This
way the "bounciness" will be contained within those limits. Then you can
do a quick tween using linear interpolation to the extreme colors.

Or, you can provide your own tweening function. You actually don't need to
modify the library. Instead, if you give it an easing function on the 4rth
parameter, tween will use it.

Another topic - text seems to be handled differently than other objects:

Indeed. Tweening is only done with numbers. No text.

1. Can't get tween.reset followed by a function call to text() to
   restart. Have to reload all the text settings.

I'm sorry, I don't understand this. Can you produce a .love file
illustrating this issue you are having?

1. Can't change text="something" to change text as text moves aroung
   screen.

Are you looking for a gradual change, or do you just want the text to
change at a given time? In the first case, sorry, but that's not
supported.
I don't think I'll be able to implement interpolation between strings. I
don't have a lot of time, and it seems like something that not a lot of
people will use.

If you just want the text to change from one value to another after some
time, you can use the callback parameter to change the text:

local message = { x = 0, y = 0, text = 'hello!' }

tween(3,message, {x=300, y=300}, 'linear', function() message.text = 
'bye!' end)

If you need to change the text more often than that, I recommend you to
give a look to my other library, cron.lua. It will allow you to change the
text more easily.

1. The same code produces different color transitions for the text when
   using Love and Lua.

This is probably not related with the text itself, but with the "linkage
problem" that you mentioned before (point 1). Applying any of the
solutions I mentioned should solve this.

Sure would be nice to have some documentation in 'tween' to help find out
what's going on.

I'm sorry you didn't find the documentation satisfying enough. I did as
much as I could, but unfortunately my time was limited. What, exactly, do
you think is missing?

Nice effects but struggling to control.

I hope this post helps you on that.

I'll leave this issue closed for now. If you need further assistance,
please let me know here and I'll re-open (I'm not sure you will have
permission to re-open it yourself, if yes, please do so if you need to)

Regards!

Reply to this email directly or view it on GitHub:
#3 (comment)

[norealname]

Hi kikito!
Just a couple of quick questions regarding 'tween' library.

What is the syntax for passing the 'p' parameter to Elastic to change the
extent of overshoot?

Is there a way to reduce the slow start of the 'in' easings. They seem to
take too long to get started causing a hesitation when looping (see attached
love script - the orbiting ball).

Couldn't figure out why you changed the 'outBounce' function from Enrique
García Cota's version. I was unable to see any difference between the two
versions.

Best,
Guy

---

From: "kikito"
[email protected]
Sent: Friday, May 13, 2011 5:18 PM
To: [email protected]
Subject: Re: [tween.lua] Apparent problem with colors (#3)

Hi norealname!

You have written quite a lot! Let me answer point by point

1. There appears to be some linkage between changing colors in one event
   and another event. The order of events is critical to obtain the assign
   color.

The only scenario where I can see this happening is when you use the same
variable for two different sources. Example:

local red = {255,0,0}

local foo = { color = red }
tween(1, foo, { ... })

local bar = { color = red }
tween(1, bar, { ... })

The problem on the code above is that both foo and bar store a reference
to the same table - in this case red. The tweens are being told to "fight"
against each other in order to change the same variable. This will not
happen if you simply specify {255, 0,0} in both cases:

local foo = { color = {255,0,0} }
tween(1, foo, { ... })

local bar = { color = {255,0,0} }
tween(1, bar, { ... })

This makes two separate tables for the color, so there's no "linkage".
Another option would be using a table that clones tables:

local function copy(t)
 local other = {}
 for i=1, #t do other[i] = t[i] end
 return other
end

local red = {255, 0,0}

local foo = { color = copy(red) }
tween(1, foo, { ... })

local bar = { color = copy(red) }
tween(1, bar, { ... })

Of course, there's lots of room for variance here - let me know if the
point wasn't clear enough.

1. Some of the colors returned are less than zero. This doesn't seem to be
   a problem with 2DLove but Lua won't accept.
   I had to add checks like if r < 0 then r = 0 end etc. Not all 'easings'
   seem to produce these errors.

Indeed. back, bounce and elastic functions will tween the values slightly
"above and below" the limits. This is their expected behavior. I can't add
the checks you suggest because in that case the "positions" will not look
"bouncy".

If you want to use back, bounce or elastic easings for tweening colors,
then the simples solution be to add some "safety space". Instead of going
from "full red" (255,0,0) to "full white" (255,255,255) use something less
extreme, like (220, 20, 20) for red and (220, 220, 220). For white. This
way the "bounciness" will be contained within those limits. Then you can
do a quick tween using linear interpolation to the extreme colors.

Or, you can provide your own tweening function. You actually don't need to
modify the library. Instead, if you give it an easing function on the 4rth
parameter, tween will use it.

Another topic - text seems to be handled differently than other objects:

Indeed. Tweening is only done with numbers. No text.

1. Can't get tween.reset followed by a function call to text() to
   restart. Have to reload all the text settings.

I'm sorry, I don't understand this. Can you produce a .love file
illustrating this issue you are having?

1. Can't change text="something" to change text as text moves aroung
   screen.

Are you looking for a gradual change, or do you just want the text to
change at a given time? In the first case, sorry, but that's not
supported.
I don't think I'll be able to implement interpolation between strings. I
don't have a lot of time, and it seems like something that not a lot of
people will use.

If you just want the text to change from one value to another after some
time, you can use the callback parameter to change the text:

local message = { x = 0, y = 0, text = 'hello!' }

tween(3,message, {x=300, y=300}, 'linear', function() message.text = 
'bye!' end)

If you need to change the text more often than that, I recommend you to
give a look to my other library, cron.lua. It will allow you to change the
text more easily.

1. The same code produces different color transitions for the text when
   using Love and Lua.

This is probably not related with the text itself, but with the "linkage
problem" that you mentioned before (point 1). Applying any of the
solutions I mentioned should solve this.

Sure would be nice to have some documentation in 'tween' to help find out
what's going on.

I'm sorry you didn't find the documentation satisfying enough. I did as
much as I could, but unfortunately my time was limited. What, exactly, do
you think is missing?

Nice effects but struggling to control.

I hope this post helps you on that.

I'll leave this issue closed for now. If you need further assistance,
please let me know here and I'll re-open (I'm not sure you will have
permission to re-open it yourself, if yes, please do so if you need to)

Regards!

Reply to this email directly or view it on GitHub:
#3 (comment)

[kikito]

Hi norealname!

What is the syntax for passing the 'p' parameter to Elastic to change the extent of overshoot?

You can't do it directly. If you want to change p or a, you will have to create your own interpolation function, and add those parameters there:

function myInElastic(t,c,b,d)
   return tween.easing.inElastic(t,c,b,d, 0.5, 1.2) -- a = 0.5, p = 1.2
end

tween(3, subject, {x=100, y=100}, myInElastic)

I confess that I haven't tried this.

Is there a way to reduce the slow start of the 'in' easings. They seem to take too long to get started causing a hesitation when looping (see attached love script - the orbiting ball).

I didn't receive your attachment. Can you use the LÖVE forum instead?
http://love2d.org/forums/viewtopic.php?f=5&t=3015

I don't know what you mean by "slow start". Depending on what family of
curves you use, the start will be either slow or fast.

Couldn't figure out why you changed the 'outBounce' function from Enrique García Cota's version. I was unable to see any difference between the two versions.

I am Enrique García! :) You probably mean Emmanuel Oga.

The reason I changed them was that there was code duplication on Emmanuel Oga's implementation. The same functions repeated the same lines again and again, sometimes changing one or two lines of code, or changing their order.

This is not a good way to write code; If you detect a bug, you have to change it in 4 places, and "hunt it down". If you extract the repeated code to a function, if there's a bug, you change it in one place and it's solved in 4. This is called the DRY principle - http://en.wikipedia.org/wiki/Don%27t_repeat_yourself .

Regards!