Input seems delayed in old and new (at least mouse does).

Edit - My tests were flawed, so the results were wrong.
See my posts below for an update.
https://forum.unity3d.com/threads/i...-new-at-least-mouse-does.404512/#post-3002560

-----------

Me and someone else were talking about the mouses input (I did not test keyboard inputs) and how it is a few frames delayed, which you can see here...
(multiple videos included, the second video is more clear)
http://forum.unity3d.com/threads/ca...oing-on-with-unity-input.403946/#post-2635149

I decided to see if the new input system would fix this, so I downloaded the sample scene and edited a few things to get the mouse to show (had to hack it in, I agree with the note in the Cursor class "//REVIEW: directly linking these two states is probably bogus" as it seemed that the mouse would not work unless it was locked, which would also make me not see it).
After doing the same test I did in the forum post above, I see the same input lag.

Even though the FAQ states
"Is it possible to poll input at higher frequency than the frame rate?
Not yet but it's planned. It will be possible to get the input in event form and check the time-stamps of each event. Alternatively it will also be possible to just poll the input state in FixedUpdate rather than Update."

I have a feeling that this delay wont be fixed by the above.
What exactly is going on?
When I tested with a old non unity game, I was expecting to get a mouse delay of 0 - 1 frames, but to my surprise, while there were sometimes 0 or 1 frame delay, there would also be 2 frame delays (never saw over 2). Which leads me to think maybe its not just unity, but in unity, I seem to get no less than 2 frame delay, many times 3 frames (actually, it might have always just been 3 frames delay), which makes me think unity is doing something to cause a delay.

Edit - I did a test with a target framerate of 15, and even then I still had a 3 frame delay in mouse input (did not test keyboard). This means that the lower your framerate, the more noticeable the delay. (This test was done on the old input system since it seems the old and new are the same in regards to this issue).

 

Bump! This issue really needs to get addressed! Three frames of lag is unacceptable. .

 

As you pointed out yourself, this is not directly related to the new input system.

The best course of action would be to file a bug report with a repro project that clearly showcases the issue. Thanks!

 

Edit - My tests were flawed, so the results were wrong.
See my posts below for an update.
https://forum.unity3d.com/threads/i...-new-at-least-mouse-does.404512/#post-3002560

----------

I just spent a while trying to figure out if the delay is truly on unitys side by creating a program outside of unity and testing mouse inputs.
Since I have no idea how to really create programs outside of unity, I was having trouble trying to have unity and the outside program working together to figure out the delay. I ended up using the systems time, but I read that has a update delay, so I dont know how accurate my test can be. I also tried to match the framerates of about 60fps, but I was using Thread.Sleep() to do it and I read that is inaccurate as well.
Ive seen 4 frame delay of input, and then 0 frame delay of input, and then 1 frame delay of input. It seems to usually be fairly close, but I feel I am not correctly testing this.
Creating a good repro of this might be out of my league =).

So I just went back to recording the mouse for my own sake to see if my application outside of unity set to a frame of 30fps compared to unity in 30fps would have the same mouse delay like in the video in my original post linked thread. (I needed to do 30fps since I was using OBS to record and its limited to 60fps).
What I found was...
-My application outside of unity seems to detect the mouse movement right on the next frame that runs as desired. So, mouse moves in middle of frame 0, frame 1 mouse movement is detected.
-Unity seemed to be 1 frame later. So, mouse moves in middle of frame 0, frame 1 passes, frame 2 mouse movement is detected.
But wait, only 1 frame? Before in my video I was seeing about 2-3 frames delay on average. What am I doing different?
Well, the only thing different that I can see was the video recording software that I was using. I was using OBS for this test, but my previous test where I made the video, I was using Fraps. So I redid the fraps recording and still was getting a 2-3 frames delay! (Except if I lock unity to 1fps then its a 1 frame delay).
If only I could have fraps record windows console (which is what my application is), then I would be able to see if fraps is whats causing input delay.
So instead, I went to the old game again like in my previous test, and even with fraps it seems the mouse doesnt have a delay like in Unity.

So I looked up some info about the game and found out it was running on directX 9 and my unity editor was running directX 11, so I used the command line -force-d3d9 to force it to run in dx9, recorded with fraps, and HAZA! it went back to a 1 frame delay instead of the 2-3. So it seems something with the graphics is affecting the input.
I did a quick search and it seems someone else saw this issue http://forum.unity3d.com/threads/input-lag-when-using-dx11-even-with-high-fps.296730/
I also saw people talking about unity and dx11 input lag here
https://forums.oculus.com/vip/discussion/9048/dx11-related-lag
Someone mentioned a bug about QualitySettings.maxQueuedFrames not working on dx11. Looking at that here in the docs it mentions input lag.
http://docs.unity3d.com/ScriptReference/QualitySettings-maxQueuedFrames.html
I went to the dx11 unity and set maxQueuedFrames to 0, but still saw lag.
I went to the forced dx9 unity and set maxQueuedFrames to 0 to see if the input lag would reduce even more and even increased it to 10 to see if it would lag more, but in both cases it was still 1 frame lag; mouse moved in middle of frame 0, frame 1 passed, frame 2 mouse detected. The desired result would be for the mouse to be detected in frame 1.
(Also note - its hard to test this since there are times when it seems like there is no frame delay, but the delay is hidden behind the video not capturing the mouse at the right time).

I also forced unity to use opengl with -force-opengl which made it use opengl 2.1 (deprecated) and the input lag returned. Went back to dx9, and it was back to only 1 frame delay.

How do I go about reporting this bug? Will just showing videos be fine?

@Crystalline if you force your unity game to run in directX 9, does the input lag go away?

 

Edit - My tests were flawed, so the results were wrong.
See my posts below for an update.
https://forum.unity3d.com/threads/i...-new-at-least-mouse-does.404512/#post-3002560

-----------

You mean a camera in real life? I dont got one of those =(, unless if a tablets camera would suffice (probably not ^^).

I did some more testing.
I found that OBS rendering of the mouse is delayed, making it seem like the input was faster when obs was recording compared to fraps.

I decided to instead of using my own application, to use the blender game engine. I believe blender was using OpenGl 4.2 for me, so I forced unity to use that as well.
Edit - Video removed due to inaccurate tests

Vsync was disabled for all tests since I read it can cause input delay.

Blender and unity opengl 4.2 when fraps is recording are both 2 frame delay
(start moving in middle of frame 0, frame 1 passes, frame 2 passes, frame 3 movement detected).

Blender and unity opengl 4.2 when OBS is recording are different.
Blender has 0 delay (start moving in middle of frame 0, frame 1 movement detected).
Unity has 1 frame delay (start moving in middle of frame 0, frame 1 passes, frame 2 movement detected).
Even though OBS rendering of the mouse is delayed, since we are using OBS for both I would assume its fine for testing to see if unity has more of a delay than blender, however, although it seems unity has 1 frame delay and blender has 0, in actuallity it might be that unity has 2 frames delay and blender (and my own application) has 1 frame delay.

I dont know if blender supports directX, so I just tested unity with directX 9.
A few interesting things I noticed. I was having unity locked at 15fps and using 30fps with half-size enabled in fraps (I believe fraps will record at 15fps though since unity was at 15fps). What I noticed was it seemed like unity had a 0 frame input delay. Also, when I was watching the frame the mouse moved and when it was detected I noticed that there were times in the recording where the Mouse value changed, but my camera didnt rotate yet. Its almost as if fraps recorded that frame right after the UI was updated, but before the camera was rendered. Is this possible? It makes all my tests even more unreliable.
I then made fraps record at 60fps full-size (again, I think it will still record at 15fps), and I noticed a time where unity was 1 frame delay again. Makes me think that the more work fraps is doing, the more it is delaying things for unitys input.
OBS still showed unity having a 1 frame input delay though, so either even though it seemed fraps was giving a 0 frame delay, it was really a 1 frame delay that the recording wasnt fast enough to detect since fraps locks it at 15fps, or OBS has the ability to also cause unity to have a high input delay depending on how much work it is doing.

So since both unity and blender have a input delay increase when fraps is in use, its probably not unitys fault, but since directX 9 seems to fix that issue, maybe unity could see why it is and put out a fix?
Also, its unsure if those other applications have a 0 frame delay since OBS mouse is delayed, but it does seem like unity might have at least a 1 frame delay extra than other applications.
However, since I am using screen recorders and not a high speed real life camera, these tests are kinda hard to accurately judge by.

If anyone else can let me know of a way to properly test this, or maybe someone with a fast camera can test the speeds.
Im including the blender game test and the unity project here in case anyone wants to compare.
For the blender game, just start the game (press P, esc to stop game), move the mouse and it will tell you if the mouse moved.

 

Isn't this a very very old observation?
http://forum.unity3d.com/threads/1-frame-lag-with-all-control-input-rage.189300/#post-2739874

I can think that fixing this may be very hard, suspecting that Unity fetches Input from the OS and needs to process it to be used within its Input class will always introduce some delay. We'll see how the low-level implementation of the new Input handles that when they start to code on it.

But not to deny its relevance, it is very visible: below is the hardware cursor, above is a UI-Image moved onto mousePosition(with offset) in Update (the gif-recorder drops some frames but it is clear that it lags behind)

 

Any updates on this? Seems like it should be the #1 priority of the entire new input system

 

Why are they ignoring this huge issue? I have tried everything possible and it still doesnt feel any close to other games. Leads to bad accuracy for shooters...which is not good.

 

Like I said before: The best course of action would be to file a bug report with a repro project that clearly showcases the issue. We do not use the forums to track issues.

If there was a bug report number posted somewhere then I missed it.

 

A bit unrelated, how does one use hardware mouse instead of the 3-frames delayed unity mouse position? I am creating a FPS shooter and it doesn't feel right with this delay/lag.

 

You cannot get the hardware position of the cursor:
https://forum.unity3d.com/threads/cursor-position.168067/#post-1150354

Unity fetches input somewhere before or at the start of each engine loop and those values stay the same for the whole loop. The only method of improving that is by increasing the engine-loop-interval through increasing your framerate i guess. Do you use VSync? You could try to start my "FPS-Trainer"-WebGL in my signature and tell if you also feel the lag there, i think i turned off all delay sources i could think of for that built back then and it should try to run at 144fps

Apart from that
Why would you need mousePosition for an FPS? In general you use Input.GetAxis or Input.GetAxisRaw but yeah, these also suffer from some Delay.

I am curious, how exactly did you get your "3-frames delayed" measurement?
It is very important to show how we gathered these delay-measurements. If it is way more than one frame we have an issue, if not, i think there is not much that can be done about it.

 

I have revisited this input issue and found a few things.

I created a few test scenes, which can be found here
https://github.com/HiddenMonk/UnityInputLagTest

All tests were done with no VSync, and QualitySettings.maxQueuedFrames = 0
Also, these tests are just in regards to windows. Anything else is not tested.

First - all my previous tests were wrong. You can see from my previous posts I was seeing inconsistencies based on the recorder I was using and what not, and what I have found was that Fraps seems to be showing the mouse cursor on the wrong frames.
I was able to confirm this by using my "Detected Input lag" test scene, which logs when input was sent, using windows mouse_event (or SendInput) command. Fraps showed that the mouse moved a few frames before the game even logged it moved. This is why it seemed like there were a couple of frames of input lag.


I contacted a youtuber named Battle(non)sense, who does analysis of games, such as for their networking or input lag, if he could use his high speed camera to do a few tests, and he very kindly agreed to help ^^.

What we found was that with a 1000hz mouse, a monitor at a refresh rate of 144hz and framerate of 144, there seemed to be about a 5 frame delay from when the mouse was pressed to when the screen reacted or logged the frame that the input was pressed. We tested on both "Fullscreen windowed" (which has more input lag and is used by default by unity) and "Exclusive fullscreen" which has less input lag, and they both gave similar results. We also tested at 144hz 500fps (we used dx9 since dx11 couldnt get past 320 or so framerate for some reason?) and it seems there were 10 to 20 frame delay (hard to tell), which make it seems like this isnt a frame issue, but a time issue.

Here are the results in terms of total milliseconds lag.
Please note that the important test was the "exclusive fullscreen" test, which unfortunately we only did one of since we didnt realize in the beginning we were testing with borderless fullscreen.

Spoiler: Click for results

Here are the high speed recordings

Spoiler: Click for video

When compared to Battle(non)sense previous input tests of other games, it seems unity is around the same in terms of ms lag, but this test scene was a very simple test scene, and those games are high end games. Would unity have more input lag if the scene was very demanding?

Here are the input lag results of other games or engines based on Battle(non)sense tests
Sample Size: 20
Monitor ASUS PG248Q
-----------------------------
Overwatch - 144Hz, exclusive Fullscreen:
300fps - 30ms(min), 36.72ms(avg) , 43.33ms(max)

CS:GO - 144Hz, exclusive Fullscreen:
142fps - 30.83ms(min), 36.11ms(avg) , 45ms(max)
400fps - 25.83ms(min), 31.39ms(avg) , 38.33ms(max)

Unreal Engine 4 Test Scene - DX11, 144Hz, exclusive Fullscreen:
1000fps - 24.17ms(min), 28.89ms(avg) , 35ms(max)

Spoiler: Sources

- Sources -

-----------------------------
Compared to unity
Unity3d Test Scene – DX11, 144Hz, exclusive Fullscreen:
144fps - 30ms(min), 37.22ms(avg) , 45ms(max)

However, remember this is a simple test scene, while the games are full fledge high end games.
Also, since we are comparing against complete games, it is unsure if there is extra code in those games that purposely causes the input to lag a bit.

The 5 frame delay worried me. So I used a program called OllyDbg to look at the assembly code and memory of the unity build, and what I found was that unity was using windows Raw Input normally. That is, they poll PeekMessageA to see if there are any messages, if so they grab the message and check if its of type WM_INPUT, if so they call GetRawInputData to get its data and then rinse and repeat for all the input messages that are there. I also saw that the memory that GetInput or mousePosition use were being written to every frame. This implies that there should be no frame delays and that unitys input system is correctly polling every frame for input and updating the values.
To further support this claim, I also have a "Auto Input lag" test scene that uses windows "mouse_event" or "SendInput" command which, I have confirmed with ollydbg, sends the command to the raw input thread as if it was an actual mouse sending the input, and when calling this in unity, unity properly detects it the next frame.
So unless if unity is purposely limiting how much input is being updated somewhere that I cant see, I dont think there is any frame delay caused by the input system.

Spoiler: Click for OllyDbg image

So why do we see a 5 frame delay in the high speed recording? Well, there are many variables that can cause input lag, such as the rendering system or the computer monitor itself. There is framebuffering or vsync that can cause input lag, but I disabled those already, so those shouldnt be the issue unless if QualitySettings.maxQueuedFrames = 0 doesnt actually disable frame buffering or if unity is doing something behind the scenes to still cause lag between the frame we see on the computer monitor and the frame the game is actually on. (keep in mind I already have the frame on screen being displayed as Time.frameCount + 1 since when viewing the frame on the screen we would already by running the next frame).
Monitors do have a display lag, which is how long it takes for the monitor to do any post processing on the image before it displays it (for things like scaling, interpolation, etc..). This delay can go high to something like 60ms (usually on tv screens, computer screens are faster). I dont know what Battle(non)sense monitors display lag is, as there is no easy way to test this, but I wouldnt think it would be more than 14ms.
One thing I dont understand about this whole display lag thing is that, how can a 144hz screen have a display lag of 60ms? If the screen updates every 7ms, but takes 60ms to actually process the image, how in the world is it updating at 144hz? Is it that the 60ms delay is just a initial delay, but then runs at 7ms normally afterwards, but will always be 60ms behind the true frame?


Overall, I am not sure if this 5 frame delay is actually caused by unitys rendering, or by Battle(non)sense monitor, or something else such as QualitySettings.maxQueuedFrames = 0 not actually disabling frame buffering (since I think I read that nvidia thinks 0 means use the default value of 3?). However, I am almost certain that it has nothing to do with the actual input system.


I have also pretty much confirmed that unity GetAxisRaw("Mouse X"), and maybe even GetAxis, ignores mouse acceleration. This can be seen with my "Mouse Acceleration" test scene.


So, some reasons you may experience input lag...
1 - Unity by default runs in "Fullscreen Windowed" mode, which can cause input lag. In project player settings, make sure dx9 and dx11 run in "Exclusive" mode. This can also be handled with a command line (that isnt documented) -window-mode exclusive or -window-mode borderless (Unity 5.3+ only I think?)
2 - Vsync is on. Disable it for less input lag.
3 - Frames are being buffered. QualitySettings.maxQueuedFrames should be 0 or a low value. (not sure if 0 actually disables it).
4 - Unity updates input only at the start of the frame, where as for most accurate input you would want to grab the input right as you need it. This is currently just how unity works, so you would need a high framerate for better input detection.
5 - Your monitor has a high display lag.
6 - You are grabbing input in FixedUpdate instead of Update


Once again, a big thanks to Battle(non)sense for helping me out =)
He did all the recordings (there were lots more recordings done then what I showed), calculated and provided the results image, told me about display lags, thought of the borderless window causing extra lag, and more ^^

 

Wow, thanks man, your post may be forever bookmarked in my archives of technical rigor!

I was already subscribed to Battle(non)sense, that guy rocks (Is he also austrian? That accent sounds so familiar), i like how he just annihilates all those empty claims about network stuff, like when people in Overwatch argued with me that the Tickrate of 20 (= ~+35ms compared to 60 ticks) was the main source of lag perception before being killed while it really is the client side hit detection ( client ping +your ping )

 

Thanks for the comprehensive testing!

I don't know enough about hardware to tell where the lag may come from, but I'd say that it seems fair to only blame Unity for whatever extra lag it has compared to whatever else you can find that may be faster.

So in this case, when Counter Strike Global Offensive has a lag of 27.5 ms and Unity one of 30 ms, then we can blame Unity for the difference of 2.5 ms. Once the new input system is ready (with the new back-end) it would be interesting to see if it fares any better, though I'm not so sure it will, since, as you say, the input system might not be to blame at all.

Rune

 

The milliseconds difference of 2.5, in my opinion, could just be based on luck, such as when the input was pressed within the frame. Although looking at his video again, it seems I took the 27.5 value from the 180hz section (although in another video he had it next to a 144hz section, ill update my post).

Spoiler: Click for video

Looking in the 144hz section, 2nd from the top seems to be what we need to look at, which looks very similar to unitys results. Whats also more important is probably the average input delay.

Either way, the delays we see Battle(non)sense get could be different to what someone else gets, since it all depends on multiple things such as their computer monitor. You might need to get a renderer guy in here to help explain that for us ^^.

I think the new input system is going to allow polling for input during any time within the frame? That might help with lowering the feel of the delay, but the perceived delay would be the same, at least in regards to these tests, since they just look for any input update at all, and not to see how accurate that input is compared to the true current input (such as mouse positions).

 

Humm... 2.5ms tech decrement in 20 yr ... looks like breaking the Moore's law !

 

Battle(non)sense has informed me he recently also did a test on an unreal engine 4 test scene someone gave him and the results were

Unreal Engine 4 Test Scene - DX11, 144Hz, exclusive Fullscreen, 1000fps:
24.17ms(min), 28.89ms(avg) , 35ms(max)

Unfortunately the results he gave me were based on 1000fps, where as our test was at 144fps. We did do a 500fps test, but that was in borderless fullscreen, not exclusive fullscreen, so it cant be used as a comparison.
So while the unreal engine test shows better results, it was done on a much higher framerate, which might be the reason why.

 

I also experience a huge lag with mouse on every Unity game. You can even google <Game Name> + mouse lag and if this game is made in Unity and has first person camera + shooting, you will find threads with complains. It's a pity, because I really like Unity workflow

The only time when mouse lag is barely noticeable (but still not as crisp as in quake for example) is when FPS is really high (>200-300). On 60 fps mouse lag is very unpleasant (for people like me -- unplayable) in competitive shooters.

So is there any possibilities that in near future it would be possible to make a crisp, quake-like mouse look in Unity? Or should I switch now?

EDIT: Also, I was able to use user32.dll to get mouse position and make it better, but it worked only in Editor, not in Build.

 

Hi i am making a moba, i need the mouse to be fast and precise, wich is not the case right now.
I just would like to know if this mouse problem is getting any attention from the dev team ?
btw, if you seach for "unity 3D mouse lag" in google you will get bunch of people complaining about it.

 

Nobody on this ?
Maybe there is a workaround i haven't seen ?

 

If you want to have a lagless mouse you NEED to use the hardware cursor https://docs.unity3d.com/ScriptReference/CursorMode.html

You can even change it
https://docs.unity3d.com/ScriptReference/Cursor.SetCursor.html

But if you want to do anything fancy that is lagless, you can't. You can only increase the framerate to improve the delay but you cannot get rid of it.

Afaik Unity fetches the accumulated Mouse-Input during the first frame and uses this value for the whole duration of the next frame (otherwise you cannot expect consistent values whenever you ask for the mouse value via Input.GetAxis() because they would change as your frametime progresses).

• So the value which you will use to position your software-cursor is set somewhere at the start of the frame and based on the previous frames' accumulated mouse-movement. This will always introduce lag compared to the hardware cursor of the OS

A worthy solution is to have the hardwarecursor most of the time, but when you are doing special stuff (like showing an impact indicating projector for spells and stuff) switch to the software cursor so it wont lag behind visibly


For click-to-visual-speed, that is the time it takes for your mouse-click to show a visual feedback like a muzzleflash on the screen, the best you can ever hope for is a value between 1-2 frametimes (that would be 16ms-32ms, 24 avg @ 60fps).
Why?
You will need to have the input registered within the current frame before you start building your next frame. building your frame will take up to 16ms (for 60fps) so if the screen and vsync buffer and other lag-sources are disregarded the best avg you can ever hope for at 60fps is 24ms.

As a comparison, i read somewhere a pro-drummer can discern timing differences/delays down to 8ms

 

Thank you very much @Marrt, it helped me a lot.

 

For maximum mouse handling (and touch on touch devices), you must:
- Set a small value in project settings -> time -> fixed update rate, something like 0.001 for 1000 times a second. Pick a value that matches that match refresh rate of your mouse or touch hardware.
- Perform your mouse and touch queries in FixedUpdate instead of Update or LateUpdate.

Doing this I get pretty good Input response on desktop. Android however is still very laggy

For maximum syncing, you can disable vsync in quality settings, although this will cause more rendering strain on the GPU and possible battery drain for mobile.

 

This makes no difference as all Input is currently only updated by Unity in the Update() loop.