search

kikito / tween.lua

Tweening/Easing/Interpolating functions for lua. Inspired on jQuery's animate method.
Other
582 stars 78 forks source link

Apparent problem with colors #3

Closed norealname closed 13 years ago

norealname commented 13 years ago

Have encountered problems with colors:

  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.
  2. 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.

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

  1. Can't get tween.reset followed by a function call to text() to restart. Have to reload all the text settings.
  2. Can't change text="something" to change text as text moves aroung screen.
  3. The same code produces different color transitions for the text when using Love and Lua.

Sure would be nice to have some documentation in 'tween' to help find out what's going on. Nice effects but struggling to control. Best

kikito commented 13 years ago

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 commented 13 years ago

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

From: "kikito" reply@reply.github.com Sent: Friday, May 13, 2011 5:18 PM To: guy.d.mcdonald@sbcglobal.net 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: https://github.com/kikito/tween.lua/issues/3#comment_1157717

norealname commented 13 years ago

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" reply@reply.github.com Sent: Friday, May 13, 2011 5:18 PM To: guy.d.mcdonald@sbcglobal.net 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: https://github.com/kikito/tween.lua/issues/3#comment_1157717

kikito commented 13 years ago

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!