Strange movement
-
Object stuttering when moving on a 0s timer, but not on a 60th of a second timer, object stuttering on a 1 second timer with 1 second movement duration (stutter must be every time the timer activates). Have a look: http://bit.ly/2BxoesF
-
@Aidan-Oxley I've seen this, and commented on it elsewhere. Sorry, it's one of the many bugs I haven't reported.
The workaround for the zero timer is simple.
Don't use a zero timer, instead use:
0.01666666Anything with a one second timer and a one second movement is only going to announce its movement once a second, and then... it's probably getting trapped in the same problem of a sync issue with small differences between frame rate and actual sampling rate of the timer.
-
@Deeeds Did you open the project? I do have a 0.0166... timer and it is smoother for some reason.
-
@Aidan-Oxley It's smoother for one simple reason, that I mentioned somewhere else, and hinted at above... that at 0.0166666 you're getting no sync problems with the rest of what's going on.
One of these is not correctly operating at one tick of the engine. And I think that's the word I used in the other comment. Very sorry I didn't post a bug about this. I should have, but haven't had time.
Somewhere else, @Hamed has mentioned that certain numbers are rounded to a tick. I'm not sure how accurate that is... it might only be two decimal places as per the display, or it might be more so than that.
-
@Aidan-Oxley Here's where I first mentioned this: https://forum.hyperpad.com/post/4014
-
@Aidan-Oxley At the core of this problem is an issue with how cocos2D treats time.
Even if you were to put aside or otherwise move around whatever issues hyperPad Timer Behaviour synching has, there are other issues with Actions (especially animations of transforms occurring over a specified duration with any ease curve) that stem from how cocos2D was designed and implemented around CADisplayLink without a proper respect for real time and an auditing of the game loop ticking by monitoring of a real unit of time to check to see what's going on, and release from an ever increasing hellhole once a disparity of sync occurs between attempts to update and redraw and what the system is actually doing and where it's at..
CADisplayLink is a message from iOS that's about when the screen will refresh, based on decisions the operating system is making about current situations the system perceives. Sometimes it reports at 40fps, which is horrific because it's not a divisor of 60, the game loop time just about all iOS game engines have wanted to run at prior to the arrival of the 120fps iPad Pros. Sometimes it reports at 30, 15 and other rates, which are less problematic, but still cause problems for anything naively believing CADisplayLink will always report at 1/60th of a second.
In cocos2D, the problem goes further... CADisplayLink is also used for the timing of these Action based animations of transforms and the drawing loop. This was the simplest way to do this back in the day, but not wise, even then. Instead of basing the actions on this misleadingly presumed 1/60th notification, the notification should always be correlated with real time to see what rate of refresh and update iOS is trying to achieve.
I've given @Hamed a couple of links to help him see how this can be rectified in cocos2D, and he seems quite sharp and diligent about optimisation and efficiency, so will no doubt realise he can apply the same thinking to how "Actions" use timing, and how he implements Timer Behaviours, and stalls rendering refreshes when there's no need for them.
This will solve many performance and stutter issues, not just this particular one, and improve both editors and gameplay. And greatly improve the overall efficiency of hyperPad whilst significantly boosting performance after hitting the little blockages that this kind of reliance on CADisplayLink creates.
