Why Mouse Lag
Ironsoul
Join Date: 2011-03-12 Member: 86048Members
Join Date: 2011-03-12 Member: 86048Members
<div class="IPBDescription">why is there mouse lag in ns2?</div>Hey.
I am here to discuss, and put some of my limited game development knowledge to work to try to find out why ns2 has mouse lag.
First, let us ask, what is mouse lag in games?
Mouse lag is where there is a noticable delay from when the player moves their mouse, to when the game begins updating the mouse look, and finally when the game finishes updating the mouse look.
There are some games that have it bad, fallout 3 main menu is a good place to go for an example on mouse lag, so is the skyrim main menu. Skyrim in general also has mouse lag that I would consider worse than ns2's mouse lag.
Note: I had a friend check out the mouse lag in the skyrim main menu, he couldn't notice it... but trust me, it was freaking there, and it was massive (500ms at least).
So what causes mouse lag?
is it the fps? No. why not? Because fps will affect how often the game updates, but is not necessarily accountable for a delay in mouse input.
note: It might be part of the bad mouse lag situations in ns2, but is in no way the cause.
My theory is it's down to the game loop. A game loop is a constantly looping block of code that will repeat until the engine is stopped. If the game loop is completely Linear, and there is only one game loop running for everything. Then low performance in one area of the game engine, will hold every thing back.
I don't know if uwe has a separate loop, just for input, but my guess is no.
Another thing that would also cause mouse lag is how the game engine interpolates mouse movement, also known as mouse smoothing(not acceleration). If the spark engine is using any form of mouse smoothing, then that will cause noticable mouse lag, especially if the frame rate gets low.
What is mouse smoothing? let's say that te game receives a mouse position update at 0 seconds, then it isn't until 1 second that it receives the next position, the mouse has changed quite a distance. Mouse smoothing will add in extra positions to make the transition between positions... smooth. Without mouse smoothing, the position of the character's look will simply jump to the next position, this may look a bit jerky, but is actually better, because of the fact that there is no mucking around with where the player is trying to look.
So in summary. here are my theories:
There is something funky going on in the game loop, possibly another game loop for mouse input needs to be added.
Mouse smoothing is in there, doing something to people's mouse input.
please correct me if I'm wrong, I do hope I'm not wrong, because if I am wrong, then the problem is much worse.
I am here to discuss, and put some of my limited game development knowledge to work to try to find out why ns2 has mouse lag.
First, let us ask, what is mouse lag in games?
Mouse lag is where there is a noticable delay from when the player moves their mouse, to when the game begins updating the mouse look, and finally when the game finishes updating the mouse look.
There are some games that have it bad, fallout 3 main menu is a good place to go for an example on mouse lag, so is the skyrim main menu. Skyrim in general also has mouse lag that I would consider worse than ns2's mouse lag.
Note: I had a friend check out the mouse lag in the skyrim main menu, he couldn't notice it... but trust me, it was freaking there, and it was massive (500ms at least).
So what causes mouse lag?
is it the fps? No. why not? Because fps will affect how often the game updates, but is not necessarily accountable for a delay in mouse input.
note: It might be part of the bad mouse lag situations in ns2, but is in no way the cause.
My theory is it's down to the game loop. A game loop is a constantly looping block of code that will repeat until the engine is stopped. If the game loop is completely Linear, and there is only one game loop running for everything. Then low performance in one area of the game engine, will hold every thing back.
I don't know if uwe has a separate loop, just for input, but my guess is no.
Another thing that would also cause mouse lag is how the game engine interpolates mouse movement, also known as mouse smoothing(not acceleration). If the spark engine is using any form of mouse smoothing, then that will cause noticable mouse lag, especially if the frame rate gets low.
What is mouse smoothing? let's say that te game receives a mouse position update at 0 seconds, then it isn't until 1 second that it receives the next position, the mouse has changed quite a distance. Mouse smoothing will add in extra positions to make the transition between positions... smooth. Without mouse smoothing, the position of the character's look will simply jump to the next position, this may look a bit jerky, but is actually better, because of the fact that there is no mucking around with where the player is trying to look.
So in summary. here are my theories:
There is something funky going on in the game loop, possibly another game loop for mouse input needs to be added.
Mouse smoothing is in there, doing something to people's mouse input.
please correct me if I'm wrong, I do hope I'm not wrong, because if I am wrong, then the problem is much worse.
Comments
Yesterday we played a scrim on ns2_turtle (on my server, which is also the pc i'm playing on), and on alien side i could look around fine at first, but later on in certain places or situations(usually if i ran into marines) i suddently had such strong input lag that i could barley turn. (even tho framerate didnt drop) Same happened for one of my mates.(yuuki)
And even tho the server was just freshly started for the match, and no unusuall errors in the server log, after a server restart it was ok again.
Its strange.
What we are looking into is additional frames of lag on top of this. I'm pretty sure this is being caused by the graphics card buffering multiple frames before they are displayed. Most likely this is some error in the way we are using Direct3D. The effect is pretty dependent on the graphics card and the speed of your CPU (if your CPU is slow relative your graphics card, it won't get ahead).
Also, there is no mouse smoothing.
<b>However</b>, when I do so, I seem to notice greater "mouse lag" at higher resolutions + atmospherics + aa. Would this be from a limitation of the cpu versus the graphics card? Is this consistent with Max's statement about slow CPU plus fast GFX = buffered frame delays, because the CPU is slower relative to GFX <b>at higher resolutions</b>, or is it the opposite? Hmmmm.
Interesting...
I have an Intel i7 920 @ 4.2ghz (currently) and an ATI 5850. The gfx card doesn't get taxed much, but in late game my CPU gets...abused. If I am understanding correctly, you are suggesting that my input lag would be worse in the early game when my CPU is further ahead than my GPU? That is the opposite of my experience to date.
It would however match with <b>some</b> of my play experience, where despite having FPS showing as 60+ the game <b>feels</b> laggy but this is quite rare.
(note: Seeing as this patch, even the best NS2 servers rubberband mid-end game, my first issue could largely be down to server performance.)
Either way I am incredibly grateful you are looking into it, as performance is really the only barrier between us and super fun NS2 games at the moment. The game is stunningly fun when you can simply enjoy playing it!
It's consistent with what I said, but I said the opposite of what you wrote :) If the CPU is fast relative to the card (or say the CPU has little work, like when you're in the ready room), then the CPU will finish processing the frame before your GPU does. If the CPU is allowed to go on to processing the next frame while the GPU is still working, it will get ahead and you'll feel the lag.
I commanded a lot of games in 187 and right when 188 came out I was like "what the....?" - night and day. It is especially noticable as a commander in new heliport on ns_summit. I do notice it more if my fps drops lower...
I did try to lower the pre buffered frames to 1 instead of 3 - that did improve it a bit but its still far worse than in 187 with 3 buffered frames (triple buffering was and is off).
I can imaginge this is a really hard to find bug since so much was changed in 188. But it is critical to squash it.
My idea on what could be causing it is the position in the code where the game gets the current mouse location. Did it change if you compare 187 to 188/189? Is the position saved somewhere and reused later? I hope I'm not wasting your time. :)
Awesome, that means the effect I feel at different settings is probably due to the CPU getting ahead/GFX buffering too many slow frames thing...or something... which means it will be fixed! Thanks.
Something did change between 187 and 188, which was the new occlusion culling system. Because the old occlusion culling system operated on both the CPU and the GPU, there was inherent synchronization between them. This prevented the GPU from buffering frames in the manner I mentioned in an earlier post. This is actually a good thing, because it means the CPU and GPU can be more fully utilized instead of waiting around for the other one to finish up what it was doing.
However it does mean that they can get out of sync and the graphics card can fall behind causing lag. I've just read through the NVIDIA GPU Programming Guide and they recommend an approach similar to how I implemented the r_sync command, but to allow it to buffer at least one frame (per GPU), so I'm going to implement that and we'll see where we are with regards to mouse lag.
Great! Let's hope it fixes the issue!
I sure hope your concept fixes the issue. I have my doubts though, since the driver already allows fixing this to 1 prerendered frame - which does not fix it completely. It's still worse than in 187...
I wonder if it would be possible to "move" the mouse movement into a different thread and draw it on top of the image output. This different thread could run much faster than the current one on another cpu core... So while the gpu could still pre-render frames the mouse itself in commander view / certain selection screens would not lag.
This would not fix "slow" mouse actions when the mouse itself isn't visible though (turning around etc)...
It would be interesting to know how other games circumvented this issue. The settlers 3 is an interesting example. I did play it all the time between 1998 and 2001. While the fps went down to 0.3-2 the mouse was somehow independent of that and could still be moved smoothly at <refresh-rate> fps...
I sure hope your concept fixes the issue. I have my doubts though, since the driver already allows fixing this to 1 prerendered frame - which does not fix it completely. It's still worse than in 187...
I wonder if it would be possible to "move" the mouse movement into a different thread and draw it on top of the image output. This different thread could run much faster than the current one on another cpu core... So while the gpu could still pre-render frames the mouse itself in commander view / certain selection screens would not lag.
This would not fix "slow" mouse actions when the mouse itself isn't visible though (turning around etc)...
It would be interesting to know how other games circumvented this issue. The settlers 3 is an interesting example. I did play it all the time between 1998 and 2001. While the fps went down to 0.3-2 the mouse was somehow independent of that and could still be moved smoothly at <refresh-rate> fps...<!--QuoteEnd--></div><!--QuoteEEnd-->
Are you actually experiencing the cursor lagging in commander mode? We're using the hardware cursor (like I'm sure Settlers 3 does) which is updated in the hardware independent of the frame rate of the game.
Hey, I just tested it again really closely - here's what I did: start summit, activate cheats, join rines, enter cc.
And what I found:
1. while the mouse is not over a GUI element (such as the map or the build buttons) everything is fine, the mouse is 100% responsive
2. while the mouse is over a GUI element and the fps are high (such as at the edges of the map) its a bit laggy but still okay
3. while the mouse is over a GUI element and the fps are low you can really perfectly see the huge delay of the mouse (I'd guess about 50-150ms)
Another observation: while the mouse is not over a GUI element it's small and blue - once it enters a GUI area it becomes large and orange and the lagging starts immediately.
I think this is quite an interesting observation, looks like you do indeed use the hardware cursor - as long as the mouse is not over a GUI element.
Maybe this applies to normal players' mouse delays as well? The new marine HUD was also introduced with 188....
edit: Ok, turning off the marine hud didn't change anything. It might be the way you treat the mouse while it's not visible... If you can fix it for the commander mode GUI elements it might automatically be fixed for the rest as well?
That probably won't entirely fix the problem at low fps, but it may prevent a buildup of mouse lag.