<!--quoteo(post=1886968:date=Nov 25 2011, 05:39 PM:name=konata)--><div class='quotetop'>QUOTE (konata @ Nov 25 2011, 05:39 PM) <a href="index.php?act=findpost&pid=1886968"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Do your home work instead of being hostile.
<a href="http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units#GeForce_300_Series" target="_blank">http://en.wikipedia.org/wiki/Comparison_of...orce_300_Series</a><!--QuoteEnd--></div><!--QuoteEEnd--> You're one to talk
Also, where's the 350-380 versions in that graph? Don't tell me the 300 series never had a decent mid-end candidate.
Not sure what this is all about, but the GT 320 is pretty crap, comparable to say the nV 6800 flagship-card (yes that's 5 generations back). Anyway I'm not sure why people expected a performance-increase this build, no features\changes have alluded to such a thing. I suppose there's the new occlusion-culling, but that doesn't alleviate the CPU-bottleneck we're all suffering from, so it's business as usual (individual cases notwithstanding), though we finally get to play tram again.
Oh by the by Mr. Techercizer sir, could you maybe pretty please put those words of wisdom in your siggy in text-form? It's really screwing with the layout at times.
Unfortunately machine specs aren't that useful to me if you are playing on an internet server, because the performance of the server will have a significant impact on the performance of your client.
This is non-intuitive since most released games don't behave this way, but we're still in beta and haven't finished optimizing. The reason the server affects the client has to do with client side prediction. While a lot of people expect the graphics to be the FPS limiter in a game, on a decent computer NS2 will typically be limited by the speed at which we can execute our game code. If you are getting updates from the server at a low rate, your client will have to run a lot more game code to do the client-side prediction.
For example, if your game is running at 60 FPS and the server is sending updates at 20 times per second (this is the target update rate), then for each frame displayed on your client it will predict 60/20 = 3 frames. If the server is running at 5 ticks per second, then the maximum number of updates it can possibly send to you is 5 per second. Since your client takes 16ms to compute 3 frames, it will now be running at 30 FPS because it has to compute 30/5=6 frames for prediction.
All that said, I'm not sure why build 188 would be worse than 187 in terms of performance either on the client or the server. In fact it should be a lot better on the client due to the occlusion culling changes, unless maybe you had a single core CPU (the occlusion culling is now all multi-core and will run better in parallel with the main thread) or your GPU was vastly better than your CPU. It's possible that due to the large amount of Lua code that changed something was introduced that decreased server performance, but we were looking for that during play testing and didn't see any issues.
In the next release I would like to add some anonymous statistics reporting so that we can get a better picture of what types of problems people are encountering both from the client side and the server side.
<!--quoteo(post=1886968:date=Nov 25 2011, 11:39 PM:name=konata)--><div class='quotetop'>QUOTE (konata @ Nov 25 2011, 11:39 PM) <a href="index.php?act=findpost&pid=1886968"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Do your home work instead of being hostile.<!--QuoteEnd--></div><!--QuoteEEnd--> <!--quoteo(post=1886952:date=Nov 25 2011, 10:35 PM:name=konata)--><div class='quotetop'>QUOTE (konata @ Nov 25 2011, 10:35 PM) <a href="index.php?act=findpost&pid=1886952"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The post wasn't hostile or unproductive. It gave the information required intended and to the posters accuracy.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1886971:date=Nov 26 2011, 02:12 AM:name=Max)--><div class='quotetop'>QUOTE (Max @ Nov 26 2011, 02:12 AM) <a href="index.php?act=findpost&pid=1886971"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Unfortunately machine specs aren't that useful to me if you are playing on an internet server, because the performance of the server will have a significant impact on the performance of your client.
This is non-intuitive since most released games don't behave this way, but we're still in beta and haven't finished optimizing. The reason the server affects the client has to do with client side prediction. While a lot of people expect the graphics to be the FPS limiter in a game, on a decent computer NS2 will typically be limited by the speed at which we can execute our game code. If you are getting updates from the server at a low rate, your client will have to run a lot more game code to do the client-side prediction.
For example, if your game is running at 60 FPS and the server is sending updates at 20 times per second (this is the target update rate), then for each frame displayed on your client it will predict 60/20 = 3 frames. If the server is running at 5 ticks per second, then the maximum number of updates it can possibly send to you is 5 per second. Since your client takes 16ms to compute 3 frames, it will now be running at 30 FPS because it has to compute 30/5=6 frames for prediction.
All that said, I'm not sure why build 188 would be worse than 187 in terms of performance either on the client or the server. In fact it should be a lot better on the client due to the occlusion culling changes, unless maybe you had a single core CPU (the occlusion culling is now all multi-core and will run better in parallel with the main thread) or your GPU was vastly better than your CPU. It's possible that due to the large amount of Lua code that changed something was introduced that decreased server performance, but we were looking for that during play testing and didn't see any issues.
In the next release I would like to add some anonymous statistics reporting so that we can get a better picture of what types of problems people are encountering both from the client side and the server side.<!--QuoteEnd--></div><!--QuoteEEnd-->
I assume this has something to do with why if my bullet/s hit an object and it doesn't register, my bullet still stays/returns to my gun but if my bullet fires off randomly, it stays used/gone?
<!--quoteo(post=1886971:date=Nov 25 2011, 06:12 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Nov 25 2011, 06:12 PM) <a href="index.php?act=findpost&pid=1886971"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Unfortunately machine specs aren't that useful to me if you are playing on an internet server, because the performance of the server will have a significant impact on the performance of your client.
*snip*<!--QuoteEnd--></div><!--QuoteEEnd--> Would it be more helpful if we posted what servers our FPS rates were from, then?
<!--quoteo(post=1886971:date=Nov 25 2011, 05:12 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Nov 25 2011, 05:12 PM) <a href="index.php?act=findpost&pid=1886971"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Unfortunately machine specs aren't that useful to me if you are playing on an internet server, because the performance of the server will have a significant impact on the performance of your client.<!--QuoteEnd--></div><!--QuoteEEnd-->
My results where on LAN Listen Server, Albeit it is local it is still broadcasting as a server on my LAN.
This is not the maps that you asked for but i shot a video of things in my level that where new with this last patch as well as some rendering/pathing/rifle/muzzle flash/bullet count oddities.
AMD 1090T Phenom II X6 @3.2 GHz/3.6 Turbo Core (9MB Total Cache) NVIDIA Geforce GT220 1GB with driver version 8.17.12.8579 (directx10) Win 7 Pro 64bit OS 16GB ram Running at an average of ~50FPS
This setup should be smooth as glass but it feels like way off in responsiveness, A few times my FPS tanked but they may be error on my end. Also the console was spammed with "to many particles" but I am assuming because of atmospherics.
<!--quoteo(post=1886980:date=Nov 25 2011, 06:11 PM:name=Koruyo)--><div class='quotetop'>QUOTE (Koruyo @ Nov 25 2011, 06:11 PM) <a href="index.php?act=findpost&pid=1886980"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Do you have this simplified occlusion geometry around areas in your map? (dunno if this is now in and working/needed)<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, I have everything in that i could find for needed or implemented groups in.
Kouji_SanSr. Hινε UÏкεεÏεг - EUPT DeputyThe NetherlandsJoin Date: 2003-05-13Member: 16271Members, NS2 Playtester, Squad Five Blue
Needs to be closer to the map shell. And yeah it would indeed be a better idea to post specs, client and server tickrate (screenshot of net_stats could be a good one)
Windows 7 64Bit AMD Phenom II X4 965 3.42GHz Asus M4A88TD-M EVO Mainboard MSI HD 6950 Twin Frozr III Power Edition OC Catalyst 11.10 Preview 2 Drivers G-Skill 4GB (2x2GB) DDR3 1600MHz Ripjaw
Performance seems a bit better with this patch than in 187. You're doing something right.
For me the game became alot smoother to play this patch, and my computer is worse then what many of you seem to have. I'm not sure about the fps, as I don't usually run with it on, but I didn't get any rubberbanding or input lag on the HBZ servers, changing to slightly as marine in tram when alien had 1 hive left and ~30ish sentries across the map. This is with max settings.
ATI Radeon 4800
Intel Core i5 @2.67GHz
3.5GB RAM @2.68GHz
Oh, and any reason why you type "r_atmospherics" you turn it on, while "r_atmospherics 1" turns it off? I assume the same is true for aa?
11.11b released. Noting that people who upgraded from .10 to .11 actually had a performance increase, it might be worth installing for those still having problems.
Initial severe mouse lag but not always. Improved graphics performance in 188, but I still don't get a smooth framerate unless I play <1280x720 on medium.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
anyone have any idea where the input lag is coming from? i'm noticing it too, but so far i have only been using my laptop since my desktop is down til Monday evening, so who knows if its related to performance.
anyone have any clue where it comes from? new occlusion culling system? and do we have triple buffering if so?
I'm guessing one problem causing performance issues and mouse lag might have to do with the stability of your connection. It seems like the client prediction code reacts almost instantly to dropped packets and ping spikes, making your cpu work much harder rendering predicted frames.
So instead of the world lagging out and mouse look staying the same as you would expect to be the usual symptom of internet lag, 1) Game events seem to continue on smoothly 2) But CPU gets hammered horribly causing input lag and fps drop
Atleast i believe this to be the case for me as I know for a fact my ISP is pretty ###### (updating drivers did nothing for me). Might also explain why some people seem to have gotten performance drops and others got performance increases randomly. Would be interesting to know if anything was changed in regard to how the client renders prediction since the last build? I figured this might be the case as when your internet totally drops out while ingame, the client goes crazy slow and you get copious ammounts of mouse input lag.
This might also explain the weird problems i've been having with hitboxes and rego this build (or it could be because im still really bad) where the client ends up predicting too much? I dno about this part.
<!--quoteo(post=1887088:date=Nov 26 2011, 04:15 PM:name=ironhorse)--><div class='quotetop'>QUOTE (ironhorse @ Nov 26 2011, 04:15 PM) <a href="index.php?act=findpost&pid=1887088"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->anyone have any idea where the input lag is coming from? i'm noticing it too, but so far i have only been using my laptop since my desktop is down til Monday evening, so who knows if its related to performance.
anyone have any clue where it comes from? new occlusion culling system? and do we have triple buffering if so?<!--QuoteEnd--></div><!--QuoteEEnd-->
Try these and let us know if it helps:
1) Update yor BIOS 2) Update your Chipset Drivers. 3) Update Mouse drivers (if USB) 4) Update your Graphics card drivers 5) Go into your GFX driver control panel, create a profile for NS2.exe with all Filtering, AA and Buffering to OFF. 6) Report back here :-)
Some people are going to say steps 1 and 2 should not affect this, but input lag can in fact be caused by slow communication of devices so we must look at all aspects.
<!--quoteo(post=1887139:date=Nov 27 2011, 08:54 AM:name=Obraxis)--><div class='quotetop'>QUOTE (Obraxis @ Nov 27 2011, 08:54 AM) <a href="index.php?act=findpost&pid=1887139"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Try these and let us know if it helps:
1) Update yor BIOS 2) Update your Chipset Drivers. 3) Update Mouse drivers (if USB) 4) Update your Graphics card drivers 5) Go into your GFX driver control panel, create a profile for NS2.exe with all Filtering, AA and Buffering to OFF. 6) Report back here :-)
Some people are going to say steps 1 and 2 should not affect this, but input lag can in fact be caused by slow communication of devices so we must look at all aspects.<!--QuoteEnd--></div><!--QuoteEEnd--> I would go a bit further than it not having any effect, it's a bit irresponsible to tell 'commeners' to update their BIOS. BIOS-updating has become a lot more user-friendly and safe in passing years, but it's still something you shouldn't do unless you know what you're doing, and to think it's going to help the mouse-lag issue that has just been introduced this particular build is a bit, shall we say desperate.
As for the chipset\mouse-drivers, they probably can't be blamed for this lag either, as it happened just this build, while the previous one was fine, suggests NS2 has a large part to play in this problem. But updating the drivers for your hardware is never a bad idea, worst-case scenario is you at least have fully updated everything.
Updating the BIOS these days is as easy as pressing a button, or clicking 'Next' a few times. It's only dangerous if you activly force the wrong BIOS onto your system, as there are safeguards in place from all BIOS manufacturers to stop this in both software and hardware.
As to it being irresponsible, if it were some hacked BIOS version by some random hacker, yes that would be irresponsible. From your computer manufacturer or parts supplier though is perfectly acceptible if you are having any issues with your computer.
I have seen a number of people with TF2/L4D2 input issues being fixed by updating their BIOS, I was one of those affected which is why I recommend it is at least tried.
Updating your BIOS for ASUS for example is as easy as updating your graphic driver. There's a program designed to do it, it checks the ROM, it flashes it, it then verifies it before restarting the computer so it knows it will work. If it's not going to work, it re-flashes your pre-existing ROM so nothing changes.
It only becomes dangerous if you don't know how to do it via DOS, which is lengthier and more painful so you wouldn't want to anyway.
I still wouldn't trust most people with doing that konata, somehow they'll find a way to break something, call it murphy's law.
Anyway, when everybody (or indeed many) experience the same lag-input since this exact build, I don't think suddenly everybody's BIOS\Graphics-drivers\Mouse-drivers are at fault. It just comes across as scape-goating if anything, although I'm sure that wasn't your intention.
Why should I have to update everything, even my bios when every other game runs fine as it is. Wouldn't it be up to the programers to make it work within a range of drivers versions. Maybe I'm not being clear here but What I am getting at is none of my games require the most up to date drivers to function properly, even new releases.
I can go on steam, Pick out a game to my system specs,download it,load it and play it with minimal setting changes in the game it's self. I'm just not understanding why all I hear in this forum is update your life if you want to play? I almost feel like there is some stalling (personal opinion) going on waiting for the "next gen" hardware to handle this engine.
If new games or existing games use new functions of updates to graphics drivers, direct x etc. it causes conflicts. Keeping everything up to date eradicates this problem.
Refusing not to update all your drivers etc. is foolish and only goes against yourself for the sake of putting up a stance and ruining your own enjoyment.
<!--quoteo(post=1887256:date=Nov 27 2011, 06:57 PM:name=konata)--><div class='quotetop'>QUOTE (konata @ Nov 27 2011, 06:57 PM) <a href="index.php?act=findpost&pid=1887256"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If new games or existing games use new functions of updates to graphics drivers, direct x etc. it causes conflicts. Keeping everything up to date eradicates this problem.
Refusing not to update all your drivers etc. is foolish and only goes against yourself for the sake of putting up a stance and ruining your own enjoyment.<!--QuoteEnd--></div><!--QuoteEEnd-->
I never said I refuse but it shouldn't be recommended with every patch. Your seem to be closed minded about the general population of PC users that let windows check for updates, not the individual programs.
Certain new games warrant graphics-driver updates. Rage for example: brand new method of texturing the world, without precedent on such a scale and complexity. NS2 on the other hand, what kind of state-of-the-art technique did it suddenly start to use going from build 187 to 188? Much less one that warrants a bloody BIOS-flash, jesus.
I think it's safe to assume the problem lies with the Spark-engine, which is fine mind you, we are in beta (*cough* alpha *cough*) after all, so I'm certainly not demanding any kind of decent performance at this point (would be nice though!). But don't try to even slightly shift the blame in this regard.
Comments
<a href="http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units#GeForce_300_Series" target="_blank">http://en.wikipedia.org/wiki/Comparison_of...orce_300_Series</a>
<a href="http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units#GeForce_300_Series" target="_blank">http://en.wikipedia.org/wiki/Comparison_of...orce_300_Series</a><!--QuoteEnd--></div><!--QuoteEEnd-->
You're one to talk
Also, where's the 350-380 versions in that graph? Don't tell me the 300 series never had a decent mid-end candidate.
Oh by the by Mr. Techercizer sir, could you maybe pretty please put those words of wisdom in your siggy in text-form? It's really screwing with the layout at times.
This is non-intuitive since most released games don't behave this way, but we're still in beta and haven't finished optimizing. The reason the server affects the client has to do with client side prediction. While a lot of people expect the graphics to be the FPS limiter in a game, on a decent computer NS2 will typically be limited by the speed at which we can execute our game code. If you are getting updates from the server at a low rate, your client will have to run a lot more game code to do the client-side prediction.
For example, if your game is running at 60 FPS and the server is sending updates at 20 times per second (this is the target update rate), then for each frame displayed on your client it will predict 60/20 = 3 frames. If the server is running at 5 ticks per second, then the maximum number of updates it can possibly send to you is 5 per second. Since your client takes 16ms to compute 3 frames, it will now be running at 30 FPS because it has to compute 30/5=6 frames for prediction.
All that said, I'm not sure why build 188 would be worse than 187 in terms of performance either on the client or the server. In fact it should be a lot better on the client due to the occlusion culling changes, unless maybe you had a single core CPU (the occlusion culling is now all multi-core and will run better in parallel with the main thread) or your GPU was vastly better than your CPU. It's possible that due to the large amount of Lua code that changed something was introduced that decreased server performance, but we were looking for that during play testing and didn't see any issues.
In the next release I would like to add some anonymous statistics reporting so that we can get a better picture of what types of problems people are encountering both from the client side and the server side.
<!--quoteo(post=1886952:date=Nov 25 2011, 10:35 PM:name=konata)--><div class='quotetop'>QUOTE (konata @ Nov 25 2011, 10:35 PM) <a href="index.php?act=findpost&pid=1886952"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The post wasn't hostile or unproductive. It gave the information required intended and to the posters accuracy.<!--QuoteEnd--></div><!--QuoteEEnd-->
--Cory
This is non-intuitive since most released games don't behave this way, but we're still in beta and haven't finished optimizing. The reason the server affects the client has to do with client side prediction. While a lot of people expect the graphics to be the FPS limiter in a game, on a decent computer NS2 will typically be limited by the speed at which we can execute our game code. If you are getting updates from the server at a low rate, your client will have to run a lot more game code to do the client-side prediction.
For example, if your game is running at 60 FPS and the server is sending updates at 20 times per second (this is the target update rate), then for each frame displayed on your client it will predict 60/20 = 3 frames. If the server is running at 5 ticks per second, then the maximum number of updates it can possibly send to you is 5 per second. Since your client takes 16ms to compute 3 frames, it will now be running at 30 FPS because it has to compute 30/5=6 frames for prediction.
All that said, I'm not sure why build 188 would be worse than 187 in terms of performance either on the client or the server. In fact it should be a lot better on the client due to the occlusion culling changes, unless maybe you had a single core CPU (the occlusion culling is now all multi-core and will run better in parallel with the main thread) or your GPU was vastly better than your CPU. It's possible that due to the large amount of Lua code that changed something was introduced that decreased server performance, but we were looking for that during play testing and didn't see any issues.
In the next release I would like to add some anonymous statistics reporting so that we can get a better picture of what types of problems people are encountering both from the client side and the server side.<!--QuoteEnd--></div><!--QuoteEEnd-->
I assume this has something to do with why if my bullet/s hit an object and it doesn't register, my bullet still stays/returns to my gun but if my bullet fires off randomly, it stays used/gone?
And a +1 to anonymous reporting.
8 GB RAM
ATI 4890 HD XT
running at 15-60 fps (15 with lerk cloud-poison)
*snip*<!--QuoteEnd--></div><!--QuoteEEnd-->
Would it be more helpful if we posted what servers our FPS rates were from, then?
My results where on LAN Listen Server, Albeit it is local it is still broadcasting as a server on my LAN.
This is not the maps that you asked for but i shot a video of things in my level that where new with this last patch as well as some rendering/pathing/rifle/muzzle flash/bullet count oddities.
AMD 1090T Phenom II X6 @3.2 GHz/3.6 Turbo Core (9MB Total Cache)
NVIDIA Geforce GT220 1GB with driver version 8.17.12.8579 (directx10)
Win 7 Pro 64bit OS
16GB ram
Running at an average of ~50FPS
This setup should be smooth as glass but it feels like way off in responsiveness, A few times my FPS tanked but they may be error on my end. Also the console was spammed with "to many particles" but I am assuming because of atmospherics.
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/3s_SXGh-Smo"></param><embed src="http://www.youtube.com/v/3s_SXGh-Smo" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
For the first few minutes i was running at 30fps which is half of what i was getting in 187..
Then it just doubled to 60fps which is similar to what i had in 188...
This was playing the server i normally play at which is a beefy one so it holds 20-30 tick rate...
Let me know if you would like any more info guys...
Yes, I have everything in that i could find for needed or implemented groups in.
OcclusionGeometry Group Shown Below.
<img src="http://www.super-nova-team.com/ns2/clandestine/occlusion.png" border="0" class="linked-image" />
AMD Phenom II X4 965 3.42GHz
Asus M4A88TD-M EVO Mainboard
MSI HD 6950 Twin Frozr III Power Edition OC
Catalyst 11.10 Preview 2 Drivers
G-Skill 4GB (2x2GB) DDR3 1600MHz Ripjaw
Performance seems a bit better with this patch than in 187. You're doing something right.
ATI Radeon 4800
Intel Core i5 @2.67GHz
3.5GB RAM @2.68GHz
Oh, and any reason why you type "r_atmospherics" you turn it on, while "r_atmospherics 1" turns it off? I assume the same is true for aa?
11.11b released. Noting that people who upgraded from .10 to .11 actually had a performance increase, it might be worth installing for those still having problems.
MSI 790GX-G65 mobo
Corsair Dominator 8 gb RAM
MSI 460gx 768 mb gfx-card
Driver: FW 280.26
Win7 64bit
Getting 70 fps in RR, 40-50 start of game. 15-30 mid-late game. Atmospherics on.
Windows 7 SP1
MacBookPro6,2
Core i7 M620 @ 2.67GHz
8GB DDR3 @ 1067 MHz
GeForce GT 330M 512MB
OCZ Vertex 2 120GB SSD
anyone have any clue where it comes from? new occlusion culling system? and do we have triple buffering if so?
So instead of the world lagging out and mouse look staying the same as you would expect to be the usual symptom of internet lag,
1) Game events seem to continue on smoothly
2) But CPU gets hammered horribly causing input lag and fps drop
Atleast i believe this to be the case for me as I know for a fact my ISP is pretty ###### (updating drivers did nothing for me). Might also explain why some people seem to have gotten performance drops and others got performance increases randomly. Would be interesting to know if anything was changed in regard to how the client renders prediction since the last build? I figured this might be the case as when your internet totally drops out while ingame, the client goes crazy slow and you get copious ammounts of mouse input lag.
This might also explain the weird problems i've been having with hitboxes and rego this build (or it could be because im still really bad) where the client ends up predicting too much? I dno about this part.
anyone have any clue where it comes from? new occlusion culling system? and do we have triple buffering if so?<!--QuoteEnd--></div><!--QuoteEEnd-->
Try these and let us know if it helps:
1) Update yor BIOS
2) Update your Chipset Drivers.
3) Update Mouse drivers (if USB)
4) Update your Graphics card drivers
5) Go into your GFX driver control panel, create a profile for NS2.exe with all Filtering, AA and Buffering to OFF.
6) Report back here :-)
Some people are going to say steps 1 and 2 should not affect this, but input lag can in fact be caused by slow communication of devices so we must look at all aspects.
1) Update yor BIOS
2) Update your Chipset Drivers.
3) Update Mouse drivers (if USB)
4) Update your Graphics card drivers
5) Go into your GFX driver control panel, create a profile for NS2.exe with all Filtering, AA and Buffering to OFF.
6) Report back here :-)
Some people are going to say steps 1 and 2 should not affect this, but input lag can in fact be caused by slow communication of devices so we must look at all aspects.<!--QuoteEnd--></div><!--QuoteEEnd-->
I would go a bit further than it not having any effect, it's a bit irresponsible to tell 'commeners' to update their BIOS. BIOS-updating has become a lot more user-friendly and safe in passing years, but it's still something you shouldn't do unless you know what you're doing, and to think it's going to help the mouse-lag issue that has just been introduced this particular build is a bit, shall we say desperate.
As for the chipset\mouse-drivers, they probably can't be blamed for this lag either, as it happened just this build, while the previous one was fine, suggests NS2 has a large part to play in this problem. But updating the drivers for your hardware is never a bad idea, worst-case scenario is you at least have fully updated everything.
As to it being irresponsible, if it were some hacked BIOS version by some random hacker, yes that would be irresponsible. From your computer manufacturer or parts supplier though is perfectly acceptible if you are having any issues with your computer.
I have seen a number of people with TF2/L4D2 input issues being fixed by updating their BIOS, I was one of those affected which is why I recommend it is at least tried.
It only becomes dangerous if you don't know how to do it via DOS, which is lengthier and more painful so you wouldn't want to anyway.
Anyway, when everybody (or indeed many) experience the same lag-input since this exact build, I don't think suddenly everybody's BIOS\Graphics-drivers\Mouse-drivers are at fault. It just comes across as scape-goating if anything, although I'm sure that wasn't your intention.
I can go on steam, Pick out a game to my system specs,download it,load it and play it with minimal setting changes in the game it's self. I'm just not understanding why all I hear in this forum is update your life if you want to play? I almost feel like there is some stalling (personal opinion) going on waiting for the "next gen" hardware to handle this engine.
Refusing not to update all your drivers etc. is foolish and only goes against yourself for the sake of putting up a stance and ruining your own enjoyment.
Refusing not to update all your drivers etc. is foolish and only goes against yourself for the sake of putting up a stance and ruining your own enjoyment.<!--QuoteEnd--></div><!--QuoteEEnd-->
I never said I refuse but it shouldn't be recommended with every patch. Your seem to be closed minded about the general population of PC users that let windows check for updates, not the individual programs.
I think it's safe to assume the problem lies with the Spark-engine, which is fine mind you, we are in beta (*cough* alpha *cough*) after all, so I'm certainly not demanding any kind of decent performance at this point (would be nice though!). But don't try to even slightly shift the blame in this regard.