-2

Unity: 2017.3.0f3

Use case : Move an object on click.

I often see Coroutine like the following to move object.

private IEnumerator MoveTo(Vector2 position){

    while (/*stop condition*/)
    {
        float newX = speed * Time.deltaTime;
        transform.position = /*with newX*/

        yield return null; // <-----------
    }

}

I think it should be:

private IEnumerator MoveTo(Vector2 position){

    while (/*stop condition*/)
    {
        yield return null; // <-----------

        float newX = speed * Time.deltaTime;
        transform.position = /*with newX*/
    }

}

I think that in most use case we have to wait the next frame to execute the move action otherwise we take into account the deltaTime that already passed before we managed to move the object.

What do you think ? Am I totally wrong ?

PS: I know that we can use Update() and co. for this kind of use case.

puglic
  • 109
  • 11

2 Answers2

2

What do you think ? Am I totally wrong ?

Yes, you are wrong. The first one is more correct.

Think of it more like this:

You want to move object from one position to another, the first thing to do is to calculate the distance to move the object then move to that position and then wait for a frame. You do this over and over again until you reach the destination position. This is what the first code is doing.

The second code on the other hand is waiting for a frame first then moving the object. Why wait for a frame before starting the movement? What will happen is that the movement will not start when that function is called until next frame which will introduce a delay. Unless this is explicitly what you want, you shouldn't go with it.

Programmer
  • 121,791
  • 22
  • 236
  • 328
  • Following what I understand about Unity lifecycle, in the first code, you introduce that the action began `deltaTime` seconds before. – puglic Apr 19 '18 at 14:36
  • No. I didn't mention `Time.deltaTime;` and that has nothing to do with this question. I talked about waiting for a frame and that has to do with `yield return null` only. The `yield return null` command waits for a frame. Putting it in the beginning of the function instead of the end waits for a frame then executing the code below it and there is no reason to do so. – Programmer Apr 19 '18 at 14:49
  • `deltaTime` is the most important, if we ignore it, first code could be ok. – puglic Apr 19 '18 at 15:13
  • No. Again, the only thing different in your code is where `yield return null;` is placed. Like I have said before, your code doesn't matter where `Time.deltaTime` is placed. `Time.deltaTime` will still do the-same thing it does regardless of where it is placed. What matters is where `yield return null;` is placed. `yield return null;` will wait for a frame/pause before running the code below it vs run the code then pause. Can you not read what's in my answer and the comments? What are you confused about? – Programmer Apr 19 '18 at 15:23
  • In case you ignore `deltaTime`, it's ok because you just want to execute your action in the current frame. Otherwise, if you use `deltaTime`, it mean that you need to know the elasped time between the current frame and the previous one. This introduce that your action "began in the previous frame" eg you calculate the distance done in this elasped time. No ? – puglic Apr 19 '18 at 15:34
  • Imagine the previous frame were executed 1 hour ago and the next frame will be executed in 1 second. Is that clearer ? – puglic Apr 19 '18 at 15:49
1

Not wrong at all, but I guess it doesn't make a noticeable difference most of the time? Your second version would be more accurate in some sense because I think that is really the expected behavior, that the object is rendered once at position 0 before moving on. If the moving object is a user controlled object I still think the first method is better suited because it would give the fastest feedback/response to the user without any "delay". The second method would be better for animations where it is preferred that the starting position is rendered as well (especially if the object isn't even visible before the animation starts),

Andreas Zita
  • 7,232
  • 6
  • 54
  • 115