Mouse input lag based on fps?
Ironsoul
Join Date: 2011-03-12 Member: 86048Members
Join Date: 2011-03-12 Member: 86048Members
Hello, I've been experiencing an annoying amount of mouseinput lag for quite some time now (2+ years) and have hoped that UWE would have noticed the problem and made a serious effort to fix the issue.
Of course, some efforts have been made to try to fix the issue such as jit and other framerate improving patches, but the core of the issue seems to still be here. I don't know exactly what it is as I'm not exactly a programmer nor do I have a great understanding of the spark engine.
I recorded a video of the delay in mouse look update compared to mouselook with my camera at 50fps. I know it's not fantastically clean footage, but the important elements are there (movement and response):
I slowed the footage down by 10, so it's playing back at 5fps to allow you to really see the input lag. But note that I notice this even when it's not slowed down. It would also be awesome if someone with a high speed camera and 120hz monitor could repeat this experiment. It's fairly simple, the console command I used was maxfps x where x is the maxfps. I stood in the ready room because that's where you can easily get consistent fps.
The only time I don't notice any lag at all is when the framerate is very high (around 200fps, the max ns2 will allow). I'm not happy about this fact for two reasons: First, my own computer while powerful isn't powerful enough to maintain 200fps constantly. Secondly, most other people playing the game cannot handle 200fps constantly either.
Regardless of that, the issue seems to be in how the game is either handling mouse input or how it is updating the player's view position before updating a frame. I was reading the unity (I know spark isn't unity) documentation and it has a bunch of events (hooks) that a script can make use of. One of them is the update function, which gets called once a frame.
http://docs.unity3d.com/Documentation/Manual/ExecutionOrder.html
But, another function the unity engine has is this thing called LateUpdate. Which gets called after all regular update stuff but just before the frame is rendered. While it might be a wild goose chase, I'm wondering if NS2 is failing to do such a thing adding to the problem.
I know this post is getting a bit long but I want to include as much information as reasonably possible.
60fps really is a key framerate to hit in games. But if you look at the video I uploaded, you can see that NS2 has a pretty gigantic lag between mouse movement and game update at 60fps.
I'd like to help the UWE devs as much as possible to get this issue fixed. It really should be number one priority.
As always, I look forward to hearing what other members of the community think.
Update/Comment: I would also like to say I think the raw performance of the spark engine and NS2 especially considering the heavy(entire) use of dynamic lights and lua scripting. This game's raw performance is bloody brilliant. I remember when the highest the game ran on my same hardware was 40fps. Now it's usual minimum is around 90fps. So I don't think further pure performance optimisations are needed all that much. It's more the logistics of how things happen in the engine is where the optimisations should happen.
Once again, I really like(love? probably) the raw performance of the spark engine.
Of course, some efforts have been made to try to fix the issue such as jit and other framerate improving patches, but the core of the issue seems to still be here. I don't know exactly what it is as I'm not exactly a programmer nor do I have a great understanding of the spark engine.
I recorded a video of the delay in mouse look update compared to mouselook with my camera at 50fps. I know it's not fantastically clean footage, but the important elements are there (movement and response):
I slowed the footage down by 10, so it's playing back at 5fps to allow you to really see the input lag. But note that I notice this even when it's not slowed down. It would also be awesome if someone with a high speed camera and 120hz monitor could repeat this experiment. It's fairly simple, the console command I used was maxfps x where x is the maxfps. I stood in the ready room because that's where you can easily get consistent fps.
The only time I don't notice any lag at all is when the framerate is very high (around 200fps, the max ns2 will allow). I'm not happy about this fact for two reasons: First, my own computer while powerful isn't powerful enough to maintain 200fps constantly. Secondly, most other people playing the game cannot handle 200fps constantly either.
Regardless of that, the issue seems to be in how the game is either handling mouse input or how it is updating the player's view position before updating a frame. I was reading the unity (I know spark isn't unity) documentation and it has a bunch of events (hooks) that a script can make use of. One of them is the update function, which gets called once a frame.
http://docs.unity3d.com/Documentation/Manual/ExecutionOrder.html
But, another function the unity engine has is this thing called LateUpdate. Which gets called after all regular update stuff but just before the frame is rendered. While it might be a wild goose chase, I'm wondering if NS2 is failing to do such a thing adding to the problem.
I know this post is getting a bit long but I want to include as much information as reasonably possible.
60fps really is a key framerate to hit in games. But if you look at the video I uploaded, you can see that NS2 has a pretty gigantic lag between mouse movement and game update at 60fps.
I'd like to help the UWE devs as much as possible to get this issue fixed. It really should be number one priority.
As always, I look forward to hearing what other members of the community think.
Update/Comment: I would also like to say I think the raw performance of the spark engine and NS2 especially considering the heavy(entire) use of dynamic lights and lua scripting. This game's raw performance is bloody brilliant. I remember when the highest the game ran on my same hardware was 40fps. Now it's usual minimum is around 90fps. So I don't think further pure performance optimisations are needed all that much. It's more the logistics of how things happen in the engine is where the optimisations should happen.
Once again, I really like(love? probably) the raw performance of the spark engine.
Comments
Can you provide some more information on your setup? Which device are you using (d3d9, d3d11 or opengl?)
There are a few sources of this latency. One is the handling of the input which is something that "late update" method you linked can potentially be used to reduce. Another is the rendering system. Because NS2 uses a multi-threaded rendering system, we incur a frame of latency since figuring out what to render and doing the rendering are happening at the same time. A final source of latency is buffering in the low-level graphics system, like D3D or OpenGL. By default D3D allows the graphics card to buffer up to 3 frames which means that everything you see is at least 3 frames old. It does this to allow the graphics card to always be busy and get maximum throughput. Natural Selection 2 forces the graphics card to buffer at most 1 frame to mitigate this latency.
I also found some of the videos I recorded. These were captured with a 240 FPS camera, and then I analyze them by going frame-by-frame and counting the number of frames between when the mouse moves and when the scree first starts updating. A 240 FPS camera isn't really fast enough to eliminate temporal aliasing, so it's not a perfect method, but it's pretty good.
Natural Selection 2 Build 256 running at 90 FPS
https://dl.dropboxusercontent.com/u/386361/latency/256_90FPS.MOV
Quake Live running at 125 FPS
https://dl.dropboxusercontent.com/u/386361/latency/quakelive_125FPS.MOV
Sure thing.
That video was recorded at 50fps on a DSLR.
My computer main hardware is in the youtube video page but: i5 2500 @3.3Ghz, 7970, 8GB(2x4) ram at 1333mhz.
Game settings are:Everything on low, multiccore rendering enabled(although I think that's unrelated to this issue), textures high 1360x768.
Rendering mode: Direct X 9
Game build: 257
I very much appreciate your own efforts into input lag. I don't want you to close the books on it until it's very good though. I was playing NS2 yesterday in 258 (in dx11 mode), and it could have been placibo or some real optimizational thing. Anyway, in a real game with my fps capped at 60, the input lag was causing me to track targets incorrectly which resulted in me getting killed.
Is there any way to force the game to update the mouse input and subsequent character look direction just before a new frame is rendered?
Question about dx9 frame buffer, so with the 3 frame buffer: Am I correct in guessing that at 60fps what I see is equivalent to 57fps in terms of delay?
I have some footage of a source engine game where I repeated the same test, I'll do some editing with that and upload it later on(near future). The thing that gets me with this is: Source engine at 60fps feels like Spark engine at 200fps. Heck, I can even acceptably play counter strike globo at 35fps, I wouldn't dream of that in NS2.
Once again, I'm very happy about this discussion and my major goal is helping you make sure spark engine is a truly awesome engine.
max pre-render frames is forced to 1 in ns2 according to what I just read from max, you most likely play with it at the default; thus it's slightly smoother but your input is less responsive in whatever game you gave as an example
@Max
I actually have my global settings for every game to use max-prerendered frames 1 or 0, I'm aware it negates performance (doesn't matter on my rig though) but do you think this has any side effect with the game forcing it? or does it override that
my fps was actually normal during that time, input lag was nuts; plus it was twitching/stuttering
For such a target important game, the engine just feels like it has a bit too much weight. Kind of like UT2004 is slightly more sluggish and less responsive than UT. I understand all the things like Dynamic Lighting and other computationally heavy tasks cause this issue, but I really hope Spark can be made to feel that little bit more lightweight and agile.
WHen the framerate gets worse in DX11 input lag does not seem so bad, but when it gets worse in DX9... it can get pretty narley.
@Dictator93 I would have to agree, it doesn't seem as bad. But would you agree that it's still unacceptable for such an aim requiring game?
@turtsmcgurt feel free to piggyback as long as you're aim here is not to bash uwe, but to help alert them to this serious problem so they can fix it and we can all enjoy a nice game of NS2.
@Everyone please remember this thread isn't about my own specific issue with the framerate and input lag, this is a global issue with the spark engine. The focus of this thread is to get information and ideas to help UWE solve this issue once and for all.
Thanks for the responses so far, I'm going to re record this test in 258 and do a comparison with source engine. I'll upload that video within the next 48 hours, I apologise about that but I'm rather busy with other projects.
I would suggest you use no fps limiting, DX9 fullscreen only, and then judge the mouse input.
Per Max's response, this is in fact not a a "global issue with spark" .. ?
Without framerate limiting in games my framerate will drop(especially on the level tram) to levels that I notice input lag that negatively impacts my ability to aim. When I notice these events, I turn on the fps monitor and I'm usually sitting around 70-90fps. 70-90fps is still a very high framerate.
If the maxfps command in NS2 causes odd side effects, then how it works should be modified so that is not the case.
About your comment suggesting this isn't a global issue. I would say that it is, but there are a couple of possible reasons people would suggest otherwise.
- They simply don't notice the input lag at all (less experienced game players tend not to notice input lag, they do play worse because of it but they don't care and aren't bothered).
- They do notice it but have found ways to deal with the issue: Things like strafing to aim instead of mouse tracking, or increasing mouse sensitivity to get more gross control.
- They have really really good computers and can handle a consistent high fps that results in them not experiencing the issue ever.
My main concern is for the majority of potential players of the game who have hardware not capable of running NS2 above or near 60fps. These people make up a very significant proportion of the PC player base and if they try a game they cannot play due to input lag, they'll quit. The low NS2 playercount at the moment seems to support this idea.
Input delay is about 2 frames right now, so if you have 200fps then input delay is 10ms (my math is right right?), but if you have 20fps then input delay is 100ms (1/10 of a second). So yes, you will get more input delay the less frames you get, this isn't something that can really be fixed.
If input delay were 2fps, let's start with a time based analogy.
If I'm 2 seconds behind someone. If they're at 40 seconds, then I'm at 38 seconds.
Back to fps, if input delay is 2fps, then at 200fps the after the delay equivalent fps would be 198 (200 - 2).
Unless the game only checks input every 2 frames, then what you say would be correct. If that is correct then that's a stupid thing to do. But I highly doubt that's how often the spark engine checks for input.
Oh and, I completely disagree with the notion that it's not something that can be fixed. It's something that must be fixed.
In a usual DX9 game, there's a buffer of 3fps (according to max). Which means a game running at 60fps is equivalent to a game running at 57fps. This is a delay of 17.54ms from input to frame pushed to the display. In NS2 according to max, the buffer is 1 frame, which means 60fps = 60fps.
From my terrible footage, stepping through the 60fps version, there's a 6 frame delay from mouse movement to screen being updated. At 50fps (recording framerate, I can't give any more accuracy than that sadly) 6/50 = .12 seconds or 120ms of latency. This is significantly higher than the supposed theoretical of 17.54ms most dx9 games should give and even more so than the theoretical delay ns2 should give: 16.66ms.
A note about network latency, that shouldn't come into it as mouse input and rendering is predicted on the client side.
Note about my video: I've identified a number of significant issues it has and will be creating a new one (re recording in latest build too) to be significantly better. The issues I've noticed are: Hard to tell when mouse is moved, hard to see the exact delay, hard to compare against another game engine. I'll fix these three issues for the next video.
I've always been highly sensitive to input latency. Until 257, I noticed a lot of input latency, especially after Reinforced. But after 257 the game runs with very similar input latency to other games, such that I don't notice the difference. I suspect there's a configuration difference on systems that are experiencing this issue still. If you're really experiencing 6 frames of latency, then we need to figure out what's different about your setup.
at the game running at 60fps, with my camera recording at 50fps. There's a 6 frame delay between input (mouse moved) and screen update.
that's 120ms delay.
In my source engine footage at 60fps. The delay is 1 frame (1/50 of a frame), which is calculated at 20ms delay. The delay could be even better than that in the source engine by my camera is unable to capture at any greater accuracy than that.
If we wanted to get even more scientific, I'd say that my accuracy is 1/49.5 to 1/50.5fps. Meaning: 20.2ms to 19.8ms delay.
I'm going to take a break from these forums for a bit so I can actually put together the better footage.
@PseudoKnight re: you not noticing input delay any more. Please be sure this is in fact true and not a placibo effect. I've had that happen to me a number of times in NS2 after patches, driver updates etc.
Another interesting tidbit: it takes a player 150-300ms to respond to visual stimuli and press a button.
According to wikipedia, the average input response time is 133ms, with the fastest games hitting 67ms, excluding display lag. I'd say 2-3 frames is great.
Background: I bought my 1680x1050 monitor specifically because of the minimal latency. My Razer mouse is running 500mhz / 1800DPI. I'm using raw input, low settings, DX9 and multicore rendering in NS2. I've set Nvidia settings to 1 prerendered frame (if you get over 60FPS, and you can, set to 0), performance mode, with all optimizations enabled. I keep vsync off, as well as postprocessing if I can. I'm running an equivalent to a Athlon II X4 640, 4GB DDR3 1600, GTX 460 768MB, with Windows 7 64-bit. My frame rate due to weak specs is probably my worst enemy in terms of input latency.
[edit] Looks like Nvidia disagrees with Anandtech, although now that I think about it, I think Anandtech was referring to using 0 when in conjunction with vsync. But Nvidia says 0 had no effect, and essentially ran like 1. There's an interesting debate on the Nvidia forums, with some evidence contradicting the Nvidia spokeperson's claim. In any case, 1 is perfectly fine.
I'll keep you all posted.
A fact that needs to be stated: NS2's delay is 3 frames. (Same as Quake3) This information is from Max, and can be witnessed in those videos he posted, but reading his post i can see how this could've been missed when he was talking about how he optimized it. (forcing the API to disregard it's default 3 frame delay etc)
Here is where this is briefly explained: Input handling = 1
Multi threaded rendering = 1
API = 1
Total = 3 frames
One more fact: The less FPS you have the more input delay that will naturally occur
Moving on, This is true only if you disregard that almost every single implementation of limiting frames inherently comes with input delay?? (Triple buffering helps, but its not flawless)
The Maxfps command was never, and afaik will never, be meant for the typical end user's application. It was a debug command created in the alpha days and has many downsides. (skipping frames or throwing them away in an odd fashion that can seem like skipping etc)
If you are getting 6 frames of delay, that is not typical behavior and is something you should investigate further. (we can assist)
This is the last patch that will have it, so test it quickly, but the scroll lock key will currently perform a reproducible and constant action of turning that you can use to measure input delay.
If not, windows can use its own settings to mess things up.
In that regard, mouse dpi/mouse pad are part of helping it lag less. (as in, did you exclude its not that the mouse didnt register the movement yet?)
If you have a lot of stuff on the usb channels, I would suggest lowering the clutter. Aka, start using less usb stuff & see if it works. (unplug printer, webcam etc if you have those).
I needed to install some unsigned driver in order to use the tool to change polling rate.
Anyway, I did that and the issue seems to be completely and utterly fixed. I'm stunned, because I've had this problem for such a long time I genuinely thought it was a problem with NS2.
I'm not sure if I'm still noticing the slightest amount of input lag still, where before it was so obvious it made my head hurt. I'll probably record things with my camera again eventually, but more than likely that last bit of lag is due to the screen I'm using.
Turns out all along it was something wrong with my machine.
I uninstalled the unsigned mouse driver and tried to reset things to how they were before I tried that fix. I can't seem to replicate the problem anymore. Which is good news for me I suppose.
I don't want to return to being all negative, I'm extremely happy that for all intents and purposes mouse latency is fixed in ns2 for me, thanks @Obraxis . But the question still remains: why does this problem seem to only affect ns2 where in other games like counter strike source for example it doesn't seem to be affected and still maintains a very high responsiveness.
@Ironhorse I didn't notice the maxfps stutter before mucking around with drivers. Now I do, I'm capping my fps using msi afterburner now and there doesn't seem to be any noticable stutter.
P.S. Oh computers, how wonderfully awful you can be. Stuff like this makes me want to go back to console gaming, I'll try to stay with PC though.