SpeedBased tween has innacurate timing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new C# script called Hottweentest
2. Add it to an empty Game Object
3. Paste the following code:

using UnityEngine;
using System.Collections;
using Holoville.HOTween;

public class Hottweentest : MonoBehaviour 
{
    public float Position = 0f;
    private System.Diagnostics.Stopwatch Timer;

    void Start () {
        Timer = new System.Diagnostics.Stopwatch();
        Timer.Start();

        HOTween.To(this, 1f, new TweenParms().
                        Prop("Position", 5f).
                        SpeedBased().
                        UpdateType(UpdateType.FixedUpdate).
                        OnComplete(ShowTime)
                     );
    }

    private void ShowTime()
    {
        Timer.Stop();
        Debug.Log(Timer.ElapsedMilliseconds);
        Timer.Reset();
    }
}

What is the expected output? What do you see instead?
Expected output: 5000
Output: Every time I run the game I get a different number, for example: 
5078
5053
5052
5042

What version of the product are you using? On what operating system?
Hottween 1.3.035 - Windows 8 64 bits

Please provide any additional information below.
If update type is FixedUpdate and the input is olways the same, the output 
should be olways the same, unless I'am measuring time in a wrong way.
I know float point numbers are innacurate but not as much as that.
This could sound like a small issue but has a lot of impact in my code.

Original issue reported on code.google.com by fer...@gmail.com on 1 Aug 2014 at 7:21

[GoogleCodeExporter]

Hi,

your test is done wrongly because of these reasons:

1. You're starting the Timer immediately at startup, which means that it will 
count also all Unity's own initialization methods, which add up and result in a 
fake end time. Try instead to make a coroutine out of Start, yield return a new 
WaitForSeconds(1), and only then start the tween and the timer
2. the Timer should start the row AFTER you create a tween, otherwise it will 
take into account also the tween creation time (which, considering it's the 
very first tween, means HOTween will also have to auto-initialize and thus take 
slightly longer than usual to create the tween)
3. Stopwatch and Unity's internal timers can have slightly different values

If you do the test correctly you'll see that you'll get results that vary 
between 5 and 16 MS, which is perfectly normal considering that FixedUpdate is 
called every 20 MS. Consider also that Unity "tries" to call FixedUpdate every 
20 MS, but that doesn't mean it truly happens at that interval (it actually 
NEVER happens at that interval), even if fixedDeltaTime is always reported to 
be the same.

Original comment by daniele....@gmail.com on 1 Aug 2014 at 8:12

• Changed state: Invalid

[GoogleCodeExporter]

I did the test like you said and I get results that vary between 3 and 16 ms. 
If this is an expected result then there is no bug, thanks for your time. 
This is the test made correctly:

using UnityEngine;
using System.Collections;
using Holoville.HOTween;

public class Hottweentest : MonoBehaviour 
{
    public float Position = 0f;
    private System.Diagnostics.Stopwatch Timer;

    void Start () {
        Timer = new System.Diagnostics.Stopwatch();

        StartCoroutine(TestHotTween());
    }

    private IEnumerator TestHotTween()
    {
        yield return new WaitForSeconds(1);

        HOTween.To(this, 1f, new TweenParms().
                        Prop("Position", 5f).
                        SpeedBased().
                        UpdateType(UpdateType.FixedUpdate).
                        OnComplete(ShowTime)
                     );
        Timer.Start();
    }

    private void ShowTime()
    {
        Debug.Log(Timer.ElapsedMilliseconds);
        Timer.Stop();
        Timer.Reset();
    }
}

Original comment by fer...@gmail.com on 1 Aug 2014 at 9:35

[GoogleCodeExporter]

Perfect :)  By the way, if you're curious, you could try using a stopwatch to 
check when each Unity's FixedUpdate is truly called. You'll see that it tries 
to keep a 20 MS average, meaning that if one is called after 30 MS the next 
update will try to be called after 10 MS.

Original comment by daniele....@gmail.com on 2 Aug 2014 at 8:13

[GoogleCodeExporter]

Thanks I didn't know that, I guess there is no workaround for this because 
using a non unity framework loop can cause issues with the thread safe 
restrictions. 

Original comment by fer...@gmail.com on 2 Aug 2014 at 12:35

[GoogleCodeExporter]

Yup. Though who knows, maybe something will change with Unity 5.

Original comment by daniele....@gmail.com on 2 Aug 2014 at 1:18