The documentation says it does an alpha fade of the object but in reality it also does a fadeIn on the x and y coordinates even when no target values are given which means, a fadeIn keeps an object fixed at it’s position as the fade goes from and to its coordinates when transition.fadeIn is called.
This results in unexpected behaviour f.i. if you trigger a delayed fadeIn and then set the position of the object (actually it even happens if the fadeIn isn’t explicitly delayed) as the positions are reset by the transition.
Is it meant to work like that, then it should be added to the documentation, or is it a bug?
fadeIn, fadeOut and other convienence methods are just shortcuts to the otherwise fully-fledged transition.to function. So yes, consider this as its normal behaviour.
I don’t see a valid reason just because they’re shortcuts.
Why would the coordinates be animated with a delta of 0, i.e. not at all, just because this is a convenience function (the generic version don’t do this neither).
It has no functionality besides the unwanted sideeffect of pinning an object at it’s current position and it does unneeded calculations for this too.
Create a sample project demonstrating the issue and file a bug with the link at the top of the page.
Note: I know you asked a question, but if you decide it is a bug, that is the avenue to follow.
3. On the help side, just use transition.to. I personally never use anything except transition.to() (99.9% of the time) and transition.from() (only very rarely).
I advise you to only use the transition.to() and transition.from() functions. You will gain a much better control of your game object’s behaviors using these and avoid issues like this in the future.
Those convenience functions are on my (short) list of things that I wish never existed in Corona.
Yeah I’ve moved over to transition.to/from already but I’m still kind of new to Corona - not that new anymore but I simply do have 3 projects in development and the code is what I learned of Corona as required. I just had the situation that I improved some existing code by adding a bit more hierarchy using displayGroups which required different coordinates and, as the objects also had dynamic/delayed fade in, the objects ended at different positions as before (and of course I expected the issue on my side due to the refactoring first).
You’re right about the convenience functions - given how simple and similar the generic transition.to is, there’s no need for additional variations anyway but I also understand that they’re kept to not break any existing/legacy code/projects of Corona users. I’ll file a bug later on, anyway.
I’m curious to see the bug report… you’re saying that “fadeIn” actually sets the x/y position to 0? That really seems unlikely to me, as those convenience functions have been around for a long time.
If it is doing that, it’s a legitimate bug that needs to be fixed. Fading should not have any effect on position.
If you have NOT filed this, please post back. I think it is worth examining each of the convenience functions to see if any of the others also have this issue.
It does not set them to 0, it fades/animates them but to their actual value, so the range/delta over the fading time is 0.
The simplest way to examine the problem is by just creating a rect, doing a fade over some time, f.i. like 2 seconds, and in an enterFrame eventhandler modify the x/y coordinates of the rect. The position will only change as expected after the fade. See the following code which also prints the _delayParams of the transition where the x/y coordinates are shown. This is similar for other convenience methods too.
[lua]
function printTable( t, indent )
indent = " " … (indent or “”)
for k, v in pairs(t) do
if type(v) == “table” then
print( indent…k…" = {")
if string.starts( k, “__” ) == false then
printTable( v, indent )
else
print( indent … k … “=” … tostring(v) )
end
print( indent … “}” )
else
print( indent … k … “=” … tostring(v) )
end
end
end
local rect = display.newRect( 10, 10, 100, 100 )
rect.alpha = 0.5
rect.x = 10
rect.y = 100
t = transition.fadeIn( rect, { time = 2000 } )
printTable( t )
–t = transition.fadeOut( rect, { time = 2000 } )
–printTable( t )
–t = transition.blink( rect, { time = 2000 } )
–printTable( t )
–t = transition.moveBy( rect, { time = 2000, x = 100, y = 100 } )
fadeIn, fadeOut and other convienence methods are just shortcuts to the otherwise fully-fledged transition.to function. So yes, consider this as its normal behaviour.
I don’t see a valid reason just because they’re shortcuts.
Why would the coordinates be animated with a delta of 0, i.e. not at all, just because this is a convenience function (the generic version don’t do this neither).
It has no functionality besides the unwanted sideeffect of pinning an object at it’s current position and it does unneeded calculations for this too.
Create a sample project demonstrating the issue and file a bug with the link at the top of the page.
Note: I know you asked a question, but if you decide it is a bug, that is the avenue to follow.
3. On the help side, just use transition.to. I personally never use anything except transition.to() (99.9% of the time) and transition.from() (only very rarely).
I advise you to only use the transition.to() and transition.from() functions. You will gain a much better control of your game object’s behaviors using these and avoid issues like this in the future.
Those convenience functions are on my (short) list of things that I wish never existed in Corona.
Yeah I’ve moved over to transition.to/from already but I’m still kind of new to Corona - not that new anymore but I simply do have 3 projects in development and the code is what I learned of Corona as required. I just had the situation that I improved some existing code by adding a bit more hierarchy using displayGroups which required different coordinates and, as the objects also had dynamic/delayed fade in, the objects ended at different positions as before (and of course I expected the issue on my side due to the refactoring first).
You’re right about the convenience functions - given how simple and similar the generic transition.to is, there’s no need for additional variations anyway but I also understand that they’re kept to not break any existing/legacy code/projects of Corona users. I’ll file a bug later on, anyway.
I’m curious to see the bug report… you’re saying that “fadeIn” actually sets the x/y position to 0? That really seems unlikely to me, as those convenience functions have been around for a long time.
If it is doing that, it’s a legitimate bug that needs to be fixed. Fading should not have any effect on position.
If you have NOT filed this, please post back. I think it is worth examining each of the convenience functions to see if any of the others also have this issue.
It does not set them to 0, it fades/animates them but to their actual value, so the range/delta over the fading time is 0.
The simplest way to examine the problem is by just creating a rect, doing a fade over some time, f.i. like 2 seconds, and in an enterFrame eventhandler modify the x/y coordinates of the rect. The position will only change as expected after the fade. See the following code which also prints the _delayParams of the transition where the x/y coordinates are shown. This is similar for other convenience methods too.
[lua]
function printTable( t, indent )
indent = " " … (indent or “”)
for k, v in pairs(t) do
if type(v) == “table” then
print( indent…k…" = {")
if string.starts( k, “__” ) == false then
printTable( v, indent )
else
print( indent … k … “=” … tostring(v) )
end
print( indent … “}” )
else
print( indent … k … “=” … tostring(v) )
end
end
end
local rect = display.newRect( 10, 10, 100, 100 )
rect.alpha = 0.5
rect.x = 10
rect.y = 100
t = transition.fadeIn( rect, { time = 2000 } )
printTable( t )
–t = transition.fadeOut( rect, { time = 2000 } )
–printTable( t )
–t = transition.blink( rect, { time = 2000 } )
–printTable( t )
–t = transition.moveBy( rect, { time = 2000, x = 100, y = 100 } )
