5
\$\begingroup\$

I have this running on the Update() on Unity. I am trying to create a page swipe feature on my game, but the problem is there is a half second delay when printing "dragging" to "end drag" when I release the mouse.

Does anyone have a method that will register input events faster?

void Update()
{
    if(isDragOn)
    {           
        if(Input.GetMouseButton(0))
        {
            print ("dragging");
            //moveContainers((Input.mousePosition.x - mouseLastPosition) * 0.01f);
            mouseLastPosition = Input.mousePosition.x;
        }
        else if(Input.GetMouseButtonUp(0))
        {
            print ("end drag");
            isDragMoved = false;
            isDragOn = false;
            endDrag();
        }
        else if(Input.touchCount > 0)
        {
            if(Input.GetTouch(0).phase == TouchPhase.Moved)
            {
                //moveContainers(Input.GetTouch(0).deltaPosition.x);
            }
            else if(Input.GetTouch(0).phase == TouchPhase.Ended)
            {
                isDragMoved = false;
                isDragOn = false;
                endDrag();
            }
        }
    }
}
\$\endgroup\$
  • \$\begingroup\$ I tested your code on my machine, end drag is printed immediately when I release the mouse. I suggest you do some further debugging/optimization. \$\endgroup\$ – MichaelHouse Aug 8 '13 at 3:35
  • \$\begingroup\$ I delete everything except for the print functions and it is still slow. Does that mean that my other code inside the script is affecting the update function? I always thought that how fast or slow update function is is based on what's inside this function. \$\endgroup\$ – user1555300 Aug 8 '13 at 3:54
  • 1
    \$\begingroup\$ Yes, that's true. But it's also affected by every other script's Update function. Every script on every object has an Update function, they all get run every frame. You may have too many objects, or one of your scripts has an Update function that takes a very long time to complete. \$\endgroup\$ – MichaelHouse Aug 8 '13 at 3:57
  • \$\begingroup\$ cool. I'll check it out. \$\endgroup\$ – user1555300 Aug 8 '13 at 3:58
  • \$\begingroup\$ I disabled the entire script and created a new script. I notice that when I tap, both button down and up register immediately. However, when I drag, there is a lag and button up doesn't always register. \$\endgroup\$ – user1555300 Aug 8 '13 at 6:24
4
\$\begingroup\$

There isn't going to be something "faster" than Update(reference), that runs once per frame:

Update is called every frame, if the MonoBehaviour is enabled.

If your frame rate is half a second per frame, then you'll get a half second delay. You'll need to perform some optimizations if you want faster response. Make sure your MonoBehaviour is enabled, and you're not running Update as part of a Coroutine. You can try creating a new project, and just putting your code into a new script on an otherwise empty object.

\$\endgroup\$
0
\$\begingroup\$

The mouse input can be theoretically speed up by using a callback-based input API. Because polling-based input API is going to be delayed from the actual input no matter what. Depending on the timing of the hardware, imagine at this moment the Update just passed but you are not yet at the rendering routine. If you were using callback-based input you would have 1 frame advantage and able to update the graphic in time. Unity have keep this callback data for the next frame.

Unity's New Input System is callback-based. But currently (9/9/2018) as far as I tried the callback does not occur at an arbitrary time but queued up and batched together and present the callback to you in the loop, before all Update(). There might be a way to ask the "queued up" data in the future when the API is being finalized, so I think it worths looking out for.

Because I see some touch code I am assuming you might also want the solution to work with touch input. If you use Native Touch you can receive the native touch callbacks as soon as the touch happen, which could be faster than waiting for Update. If you want the same input workflow as native app developement you might want to check it out.

\$\endgroup\$
  • \$\begingroup\$ Asker isn't having problems with touch input, but mouse input. \$\endgroup\$ – Draco18s Sep 8 '18 at 15:56
  • \$\begingroup\$ That may not be true. You can see in his Update() code there are Input.touchCount and Input.GetTouch(0), and also "Does anyone have a method that will register input events faster?", that is where I based my assumption from. And the foundation of this problem is because the check is based on in-frame input state polling in Update() instead of a callback. \$\endgroup\$ – 5argon Sep 9 '18 at 2:45
  • \$\begingroup\$ From the question: there is a half second delay when printing "dragging" to "end drag" when I release the mouse. They stated "mouse" explicitly and "dragging" as a text string only appears under the mouse input section. \$\endgroup\$ – Draco18s Sep 9 '18 at 4:22
  • \$\begingroup\$ Yes, you are correct. The asker is 100% having a problem with the mouse input. The touch problem is only a possibility, he might or might not having a problem with it. \$\endgroup\$ – 5argon Sep 9 '18 at 6:20
  • \$\begingroup\$ I have edited the answer so that the mouse problem is addressed first, and then the touch problem which might or might not be a problem is addressed second. \$\endgroup\$ – 5argon Sep 9 '18 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.