well Ive done some more playing with the settings and I think it feels a lot better now.

Just a bit of understanding first: Lots of small packets work well for digitial connections, but for adsl where processing latency is higher, and bandwidth more limited, lots of small packets are as benefitial. Latency increases reciprocally as remaining bandwidth decreases (the amount it does this depends on the technology)

However, splitting the rate up into lots of small quickly transmitted packets means that updates occur more quickly.

Hence there is always a compromise between processing latency and update rate.

Settings
========

What I noticed is that maxpacketsize affects server to client number of packets and packet size. The server rate is split up by the maximum packet size this way. The range is 20-1400, 20 gives nearly 200 packets per second, which will is unusable. Setting high values, the update rate drops to around 50/s (obviously it wont drop below server fps*). This is much more acceptable considering that the servers typically run at 45fps. This is still a lot more than Q3s 20fps. I would suggest you experiment with this value, since large packets may not be handled well by your network or routing.

*yet? Like snaps

What concerns me a lot here is that the default is 300. Well this might be ideal for servers with only a few players, but as soon as the server starts getting busy, your packets will get fragmented, and more packets mean more overhead, which means more bandwidth which means even higher latency (as well as the increased update latency).

NetUpdateSendPeriod which is controlled by ActionUpdatePeriod from command line – this is analogous to cl_maxpackets in Q3 except that it is 1000/(the value). 10ms = 100 maxpackets. As always higher update rates, mean lower update latency at the expense of increased bandwidth and the associated increase in latency with that. Play with this value, but you will find that the range over which you can play with it realistically is only, perhaps, 8-12.

Cfg.PushLatency is analogous to negative cl_timenudge in Q3. Like in Q3, it is important to get this setting correct, and requires experimentation.

I also used the new prediction, but it is important to get your basic connection settings correct first of all before using the patch of prediction. Prediction should just *help* but you need to have a playable connection without it first to get the best effect from it.

This is what seemed to work well for me:

Cfg.NetUpdateMaxPacketSize = 700
Cfg.NetUpdateSendPeriod = 10
Cfg.PlayerPrediction = true
Cfg.NewPrediction = true
Cfg.PushLatency = 25

Let me know what works well for you

THE PROBLEM
===========

The mouse lag issue [1][2] for Direct3D games is a known issue and can be seen in many Direct3D renderable games such as Halflife, UT, etc. [3][4][5]

The lag is due to the buffering that your video card is doing. Since they have eliminated any synchronization calls in the video card instruction buffer, it keeps on taking input from the CPU until the buffer is full. So your video card at any point in time may be rendering a frame that you fed it 1-3 frames beforehand, which would explain the mouse lags when at lowered framerates. In this way the CPU (via mouse events) is lagged from what is seen on the screen. [6][7]

Okay so why dont you see this in Single Player? In single player the game speed is slowed as your FPS drops, so the events take the same number of frames and appear smooth. This is typically done on every SP console game also. This effectively means that your CPU is slowed to be in sync. with your GPU. In MP this CANNOT happen, since time is constant and global (otherwise one client would time-lag the whole server, although this happens on listen servers 😉 ).

GRAPHICS CARD DEVELOPERS
========================

ATI acknowledge the problem and their fix for Direct3D games with mouse lag is…. to use OpenGL or software rendering 🙂..unless the developer forces GPU-CPU sync. themselves at the point of rendering rather than pre-rendering. This is effectively removing the pre-rendering buffer as we do in the fix.

http://www.ati.com/support/infobase/3308.html <- Unreal http://www.ati.com/support/infobase/3655.html <- Halflife (NOTE: In OpenGL you can call glFinish() to synchronise CPU and GPU after each frame. Most OpenGL games have this option) NVIDIA offer some advice to developers on the subject in their developer FAQ. http://developer.nvidia.com/object/General_FAQ.html#G4

Saying The most obvious solution would be to lock the back buffer for each frame in Direct3D, which is essentially fix presented on Pkeuro. This ensures that all pending graphics commands are completed by the GPU before the CPU moves on..

Thats why UT2003/4 had to resort having a reduce mouse lag options which is basically forces syncronisation between the CPU and the GPU, overriding the pre-rendering buffer limit.

The pkeuro fix will work for Direct3D games for this reason. You may experience a slight FPS drop, since nvidias need for a large amount of pre-rendering is based on the fact their pre-rendering code is not optimised for D3D so much. That said fps-lag is much more playable than mouse-lag.

THE FIX
=======

Click Here.

References
==========

[1] Savage General
[2] ESR
[3] Battlezone 2
[4] Unreal
[5] ElderScrolls
[6] Developer Forum #1
[7] Developer Forum #2

2. No, its not a sport; a sport is physical activity that is governed by a set of rules or customs and often engaged in competitively. Wiggling your mouse at other bored individuals in a hope to feel superior will never make you pro or a sportsman.

Discuss. 🙂