Transition/Easing 2.0?

Solar2D Daily Builds and Public Releases
#81 
local t1 = native.newTextField( 10, 300, 180, 30 ) transition.from( t1, { time = 100, x = 200 } ) transition.to( t1, { time = 100, x = 200 } )

Hey Icy Spark, everyone,

Let’s get clear on “you have to pass a display object to a transition.to call”. That means you’re calling a transition on a nil object.

It was not there in Transition1.0 and thus things were error prone.

So if you run my small snippet above, it will work. If you get the error you mentioned, then you are really calling a transition on a nil object…

Alex

#82

yeps, alexf is of course right.

In my case, i have changed a scene, tried to do a transition with a display group in the changescene method that has already been removed manually before.

now it throws an error, it didn’t before. but its better this way :slight_smile:

#83

@dingo: It´s the same case for me, so I can fix the error by myself :slight_smile:

#84

Yes I stand corrected.

The reason it wasn’t working for textFields for me was that I was checking if my code was running on simulator, which it was so the textField was never created.  I had only forward declared it.  

#85

After a bunch of testing I think my own problem was caused by two separate issues:

  1.  I was incorrectly setting a transition time variable to nil within my scene transition function.  This actually works in build 1206 where transitions default to a time of 1/2 second if no time parameter is specified (or set to nil as I was erroniously doing).  For example

    local box = display.newRect(100,100,50,50) transition.to(box,{delay = 1000, time = nil, y = 400})

This simple code above will move a box down the screen over 1/2 second in build 1206.  But in build 1207 the box will snap to the final position without any transition.  The old default behavior was masking an error in my code since the time I thought I was passing was about the same length as the default.   Now, the daily docs for transition.to still says 

params.time (optional)

Number. Specifies the duration of the transition in milliseconds. By default, the duration is 500 milliseconds

 

So either the current docs are wrong if the new intention for transition 2.0 is to not  have a default transition time, or this is a bug in transitions 2.0.

 

  1.  My second, and main problem, is caused by this chunk of code that I call within my custom scene transition function to cleanup any runtime listeners in the old scene before I create the new scene:

        --cleanup any enterFrame runtime listeners in old scene     if Runtime._functionListeners.enterFrame then         for k,v in pairs(Runtime._functionListeners.enterFrame) do             Runtime:removeEventListener(“enterFrame”,v)         end     end  

In build 1206 this works; my transitions all work, and my scenes display correctly, etc.  

In build 1207 this causes the old scene to freeze on screen.  I can tell from the console that my new scene is loading, but it isn’t displaying anything. It appears that none of the transition.to or transition.from will work once this cleanup code is run.  I’m guessing that Transition 2.0 requires something that Transition 1.0 doesn’t that is getting wiped out by that code.

Admittedly, that cleanup code is a hack to solve a different problem.  I think I have another way to work around that, so hopefully I won’t need to use it anymore.

#86

until now it all runs pretty flawless on my app.

I just had to change a little thing but now it’s fine.

I think it’s super amazing that we can just cancel, pause and resume transitions by calling the object itself in the parameter now.

that’s super awesome!

#87

Pausable transitions! Woohoo! Yes!!

Gotta’ replace my proprietary code now :slight_smile:

#88

Guys, if you have any ideas for improvement, feedback, other functionality you want to see in future versions of Transition, please don’t hesitate to write them in a thread or in the feedback tool. The current version has been built on user feedback as well, and we would like to keep that going.

There’s gonna be a minor update soon, that sets the transition time to 500msec if no time provided (was the behaviour of T1.0), brings back the convenience method transition.dissolve, and some other improvements.

@HardBoiledIndustries: using a runtime listener removal loop on the Runtime object is really a bad idea, a lot of third-party libraries and some of ours make use of global runtime listeners (enterFrame), i can only recommend to store your created listeners in a table / global object (maybe even the storyboard object itself) and just clean those up…

alex

#89

Here ya go :slight_smile:

http://forums.coronalabs.com/topic/39596-transition-20-easing-20-request/

All in all pretty happy with transitions (and the new easing) so just requesting some kind of distort feature.so i could distort the top and bottom widths of an image. :slight_smile:

#90

A selector menu in my app broke with 2013.1210:

Transition 2.0:  you have to pass a display object to a transition.to call.

stack traceback:

    [C]: ?

    [C]: in function ‘error’

    ?: in function ‘to’

    …ents/Code/gitstuff/Dawnrazor/views/LevelSelector.lua:91: in function ‘cancelMove’

As far as I can tell, I am passing a display object. It’s not triggering the print statement.

[lua]

function cancelMove()

    if not thumbs[thumbNum-1] then

        print  (“It’s nil”)

    end

    tween = transition.to( thumbs[thumbNum], {time=400, x=screenW*.5, transition=easing.outExpo } )

    tween = transition.to( thumbs[thumbNum-1], {time=400, x=(screenW*.5 + padding)*-1, transition=easing.outExpo } ) – this is line 91

    tween = transition.to( thumbs[thumbNum+1], {time=400, x=screenW*1.5+padding, transition=easing.outExpo } )

end

[/lua]

Any ideas?

#91

@Dotnaught,

You’re only checking for the existence of thumbs[thumbNum-1], but you’re doing transitions for thumbs[thumbNum] and thumbs[thumbNum+1] so maybe one of those is missing and causing your error.

@HardBoiledIndustries: using a runtime listener removal loop on the Runtime object is really a bad idea, a lot of third-party libraries and some of ours make use of global runtime listeners (enterFrame), i can only recommend to store your created listeners in a table / global object (maybe even the storyboard object itself) and just clean those up…

Yeah, I know it’s a nasty hack, but up until Transitions 2.0 it worked without issue so I left it in.  I did figure out out a way to do without it now, so the new transitions forced me to clean up my code for the better.

#92

Thanks, I think I found the nil object…

#93

Ha! Surely you jest. Here’s what’s breaking for me:

    transition.dissolve ( default, over, 10, 0 )

    transition.dissolve( oldBackground,gameBackground, 1000,0 )

I’ve tried doing two transitions, but so far haven’t found a combination that works correctly. Examples:

            transition.to( oldBackground,{ time=1000, alpha=0, transition=easing.inOutExpo } )

            transition.to( gameBackground, { time=1000, alpha=1, transition=easing.inOutExpo } )

            transition.from( oldBackground,{ time=1000, alpha=0, transition=easing.inOutExpo } )

            transition.to( gameBackground, { time=1000, alpha=1, transition=easing.inOutExpo } )

These do the transition, but there’s no easing.

#94

Build 2013.1210 is breaking here with anything using transition.dissolve.

e.g. transitionStash.newTransition_433 = transition.dissolve(ham, ham2,  0, 100)

Comes up with error:

“:attempt to call field ‘dissolve’ <a nil value>”

#95

Build 2013.1210 is throwing the

“Transition 2.0:  you have to pass a display object to a transition.to call” error in the simultator when dragging a Widget-v1 scrollview. 

Bummer for me.

Nail

#96

I read that transition.dissolve() is temporarily missing. It will be back in a build soon.

#97

Widget’s 1 is really old code.  We encourage people to move to Widgets 2 as that’s the supported version now.  If you’re still using Widgets 1, you probably will need to scrub through the code looking for transition calls and fix any nil references, or wait until we get a round of fixes out that takes care of a few of the defaults. 

#98

nilling out all the transitions in the Widget 1 scrollview has seemed to stop the error. Some of the transitions were already nil’d out, but not all of them.

Nail

#99

dupe

#100

Hey,

I had some strange behavior of my App by changing to the actual daily build with transition 2.0. After some testing I figured out, that if you set a x/y value to an object with is currently in transition, the transition will be aborted and the object will be moved to the new coordinate immediately. Thats not the case with the old transition.

Maybe this is useful for someone.