@jotajota: they accelerate at the beginning and they decelerate at the end because is uses an EaseIn (or EaseOut) action.

Yep, it seems to fix the jump from the middle issue. Well done. However, I can't say the transitions are smoother. I'm testing with SlideInRTransition.

@riq: just realized that r1113 must be a commit version on the SVN

@riq: do u mean u can't get a new scene to transate to screen jumping from the middle? Try with a full screen png as the only sprite initialized on the init of the next scene. Also why does it accelerate at the begining and decelerate at the end?. I'd expect it to be linear. What is r1113 BTW? Link?
@ob1: hey I'll try that tomorrow first thing. But just for the shake of it bc as I stated before, I fixed my issues by using several layers on the scene

I am still on 0.7.3 :-/

@ob1: I couldn't reproduce the issue, but you're right.
Your patch is correct. the first time an scheduler is called, the dt should be 0.

thanks.

fixed in r1113
Could you try test it with r1113 ?

Yeah, I didn't know if it was cleaner to put elapsed = -1 or to have a new "BOOL firstFire".

Ah.. I missed the initialize with -1.

I'll try it again.

@ob1: what cocos2d version are you using ?

I tried adding your patch, but that condition (elapsed == -1) is never triggered.

Well, my beta testers noted the problem of the non-smooth transitions and them starting in the middle. According to them (I don't know if it is psycological) my patch fixed the issue. Several other Cocos users have also encountered the problem.

However, I am unfortunately totally unable to make a test case that reproduces the problem each time. There is still something I am not understanding well :-/

Could other people who have suffering the problem test my patch ?

Jotajota, your are right it is in the Timer class (in the Scheduler.m file).

Hmm for my fix to work you need:

if (elapsed == -1)
{
elapsed = 0;
}
else
{
elapsed+= dt;
}

Did you do it that way jotajota ? without the else clause it won't do anything, sorry for the confusion.

I will try to find some time to write a test case.

ob1: thanks. Could you attach a test-code, a code that reproduces the issue ?
(please attach it into the issue entry, not here. thanks)

I don't want to apply the fix unless I'm sure that it's fixing the bug (and that is not breaking another thing).

thanks.

@ob1 I've tried what you suggest (on the Timer class though) with no improvement on my code :(

I've solved my problem by using Layers. What I wanted to achieve was to show a couple of fullscreen slides (with touch detection) as instructions. Now I'm creating the first scene and the layers at the same time and I just animate them into the screen when I need them. This way the slide-in is much faster and smoother than using Scenes for each slide.

@riq: I believe I found and fixed the problem.

When a new scheduler is added, "elapsed" is set to zero.
The first time the scheduler is fired, "elapsed" is set to dt.
This I think explains the hiccups and why transistions start in the middle.

As a fix, I put :

elapsed = -1;

in the scheduler init

and added:

`if (elapsed == -1) {elapsed = 0};

in the "fire" method.

That way, the first time a scheduler is fired, elapsed is equal to zero.

Tell me if I have correct, and if so I will open an issue.

I'm not sure what's the problem.
I suggest looking at the TransitionTest.m file, and try to create your transitions / scenes more or less they way they are created on the test.

No luck so far.

I've tried to move as much as I can to onEnterTransitionDidFinish so that the only thing I have on the init is a Sprite for the bg of the new scene (a full screen png - file size: 84KB). Do you think the problem is related to the way I'm creating the bg?

Thanks

Forgot to say: button textures are preloaded.

Thing is I don't think that 4 buttons and a bg is heavy ressource.

And it does the bug online the first time for each scene, although i recreate the scene each time.

Probably you are right. The init of the new transition should be initialized before the the creation of the transition.

So, I'm not sure why... I should look at the code again. But I remember that deferring the initialization of "heavy" resources did the trick.

riq, could you explain why "init" causes the problem ?

I suffer from the same problem and it looks to me as "init" returns before the code that setups the transition is called, therefore I fail to see why it causes this behavior.

That must be it!. I'll try and let you guys know.

Thanks riq

A tip for transitions:
the new scene should not initialize "heavy" resources on init.

If you are using v0.8, initialize them on "onEnterTransitionDidFinish" callback.
If you are using v0.7, scheduler a timer that will be called in XXX seconds, and initialize the heavy resources there.

Doing this will prevent the "starts in the middle of the screen".

Hi there,

Using different combinations of push/replace MoveFromRight/SlideFromRight, I always get the transition to the new scene some how not right. Sometimes the new scene starts showing in the middle of the screen. Sometimes accelerates abruptly at the beginning of it...

I want them to be half a second long. Could this be a problem?
Any other pointers?

Gracias amigos.