sync hz/fps/maxpackets

In ur opinon :

100 FPS , 100 maxpackets & 85 hZ refresh

or

83 FPS , 85 maxpackets & 85hZ refresh

or

83 FPS , 100 maxpackets & 85hZ refresh

others settings?

thx to help me :)
Comments
44
125 fps 100 maxpackets 85 hz rmode 6 2.2 sens 400 dpi fov 90 mx518
166 fps 100 maxpackets 85 hz rmode 6 14.10 sens 400 dpi fov 90 G5
Parent
waarom 166 fps
Parent
omdat me pc dat trekt! en overdrive zegt dat het goed is
Parent
niet luisteeren nieuwe cb config word toch geforcedom 76 of 125 te pakken dus kun je er net zo goed op blijven
Parent
cb heb ik altijd 166
Parent
76/125 fps and 100 maxpackets, others dont matter :|
76/125 it's only for jump but i don't care about jump :p
Parent
125 fps 100 maxpackets 85 hz rmode 6
100 FPS , 100 maxpackets & 85 hZ refresh
cl_maxpackets 100!!!!!! fps 125 or 76 (100 suck -,-) + max display refresh
76 fps, 100 maxpackets, r_mode 6, 85hz
first one
the third has no sens btw
85 hz ( images refresh of monitor ) and 85 FPS no sens ...
Parent
you lag then!
Parent
I just play with normal settings and thats ok. If enemy has even one guy with less then 76 maxpackets I put my on 40 :) usually it works great :)

I have 200fps, usually 100maxpackets and 75hz all the time
first looks best, but u should have higher refresh rate... wait let me guess, u are using TFT!
tft is 75hz max.
Parent
there are tfts with 85 max
Parent
orly? didnt know that.
Parent
ask alexL, he got one
Parent
but most (all) tfts update with 60hz anyway (what you can set in windows is for compatibility and the wrong setting might make things worse/slower).
Parent
no matter if they use 60 or 85, they are too slow anyway... CRT ftw
Parent
my screen can also only handle 85hz @ my res :-\
Parent
idk try to get 100hz with that uuh 1 tool =)
or maybe more hz at r_mode 4 w/e

just try SOMETHING LAL
r_mode 4 / 160 hz :< 250 hz 6th notch 400 dpi senstivity 2.5


>_< more recoil plz
100 fps - 100 maxpackets - 100 hz
r_mode 6
hz 100
r_displayrefresh 100
fps 100
maxpackets 100
r_swapinterval 0 (otherwise FPS and cl_maxpackets will be <= r_displayrefresh)

r_displayrefresh as high as your HW can handle

maxpackets/FPS 100
wth is the use of more than 85 fps when your monitor has only 85hz. U only get non drawn frames which makes your mouefeelin not as accurate afaik.btw i just play with 60fps 60hz and 60 maxpackets and it plays fine.
Acctualy its the other way around.

If your hz if faster than you produce pics then you will get black screens that cause frame tearing and in that way could create less precision with your mouse movements.
Parent
but wont u get undrawn frames if your hz is lower than your fps?
BTW would be kinda gay if new CB config would force fps settings to 76 or125.
Parent
you get unused frames yes, but if we theorize your perspective as true, then the client would decide the game speed, which is not true.
Parent
your 2nd and 3rd choise would cause frame tearing, i would go for 125 / 100 / 100 if possible
fps / maxpackets

;----Copied from Guwgl
Ingame mit reichlich Action steigen die kb send/sec um nochmal ca 1-2kb/sec an (das gleiche gilt auch fuer den Downstream). Alle Werte wurden gerundet. FPS wurden mittels com_maxfps erzwungen und waren konstant!

Legende:

maxpackets: Der com_maxpackets Wert des Clients
cstats: /cstats ist ein Command in cpma um genauere Werte über die tatsächliche Verbindungsqualität zu erfassen, die Range sollte möglich klein sein.
UDP send/sec: Die vom Client an den Server gesendeten UDP Pakete pro Sekunde
kb send/sec: Die an den Server gesendete Bandbreite in kb/sec



Keinerlei Gewähr auf Richtigkeit, wäre gut wenn es ein paar Leute geben würde, die diese Daten verifizieren könnten.

50 fps (Stillstand)
==============
maxpackets cstats (range) UDP send/sec kb send/sec
--------------------------------------------------------------------------------------
30 0-60 25 1,5
40 0-60 25 1,5
50 0-60 50 3
60 20-40 50 3
70 0-20 50 3
80 0-40 50 3
90 0-20 50 3
100 0-40 50 3

75 fps (Stillstand)
==============
maxpackets cstats (range) UDP send/sec kb send/sec
--------------------------------------------------------------------------------------
30 13-65 23 1.6
40 13-59 38 2.3
50 13-49 38 2.4
60 13-49 38 2.4
70 13-67 38 2.4
75 13-41 77 4.5
80 13-30 77 4.5
90 13-32 77 4.5
100 13-39 77 4.5

90 fps (Stillstand)
==============
maxpackets cstats (range) UDP send/sec kb send/sec
--------------------------------------------------------------------------------------
30 11-45 30 1.9
40 11-50 30 1.9
50 11-53 45 2.8
60 11-42 45 2.8
70 11-39 45 2.8
80 11-39 46 2.8
90 11-39 91 5.4
100 0-31 91 5.4

100 fps (Stillstand)
==============
maxpackets cstats (range) UDP send/sec kb send/sec
--------------------------------------------------------------------------------------
30 10-60 25 1.6
40 10-60 33 2.1
50 10-50 50 3
60 10-40 50 3
70 10-40 50 3
80 0-32 50 3
90 0-40 50 3
100 10-40 100 6

125 fps (Stillstand)
==============
maxpackets cstats (range) UDP send/sec kb send/sec
--------------------------------------------------------------------------------------
30 0-31 25 1.6
40 16-56 31 2
50 16-51 41 2.6
60 9-40 62 3.8
70 13-33 62 3.8
80 9-40 62 3.8
90 10-40 62 3.8
100 9-32 62 3.8


fps:

WARNING: EXTREMELY long post with only 1 smiley -- but it's worth it, as I answer pretty much every physics / FPS question in quake 3.

Earlier this evening, Ctrl told me that he was dissatisfied with my previous explanation of why your fps affects jumping. So, I did some more research. Specifically, I wrote a mod to measure your jumping.

Here are the key points that I discovered:
(1) The final velocity vectors are clamped to integers every time the player movement code is called. This gets called once per frame for fast clients, but never less than 20 times per second.
(2) This conversion is done by the equation (int)x, where "x" is a floating point value.
(3) The integer conversion done by the Q3 vm *IS NOT ANSI COMPLIENT*. ANSI C specifies that integer conversion is done by ignoring the fraction. The Q3 vm does it by rounding to the nearest integer.

This third point explains exactly why DLL's have slower speeds and jump heights than QVM's. In a QVM, the rounding is to nearest integer, so errors will tend to cancel out. In a DLL, rounding is always towards 0, so errors always reduce your speed and will always accumulate. The rounding error in a DLL always acts as extra friction. I expect you can get around this problem in DLL's by rewriting the "SnapVector" macro to emulate the QVM's rounding method.

Now, back to the jumps. In theory, the rounding errors should cancel out over the number of frames in a typical jump. This assumes that the fraction can be any value with equal probability. However, in practice, this is not the case. Each frame tends to be the same time as the previous one. The change in velocity is the acceleration times the frame time. Acceleration is due to gravity, and is therefore constant. Frame time is also nearly constant, so the change in velocity is also nearly constant in each frame. Since velocity always starts as an integer, and the change is always nearly the same, under a constant fps rounding has nearly the same error each frame. With a constant frame rate, Q3's rounding errors will tend to accumulate. For some frame rates, this will always round down; for others, it will always round up.

Based on this, the ideal frame rate for jumping distance is the highest one your computer can maintain that gets a fraction remainder near 0.5, but always greater than 0.5. Q3's gravity is 800, so you want the fractional part of 800/fps to be greater than 0.5. To protect against frame rate fluctuations, you'd also want nearby frame rates to have fractions greater than 0.5. Lastly, you want there to be as many frames as possible, so that the most possible positive error gets accumulated.

This chart gives (1) fps, (2) remainder of 800 / fps, (3) number of frames in 0.675 seconds, (4) maximum positive accumulated error in 0.675 seconds. The table was generated for all frame rates from 20 to 200 fps.

code:


23 0.78 15 3.26
26 0.77 17 3.92
27 0.63 18 6.67
28 0.57 18 7.71
29 0.59 19 7.86
30 0.67 20 6.67
31 0.81 20 3.87
34 0.53 22 10.35
35 0.86 23 3.29
37 0.62 24 9.08
39 0.51 26 12.67
41 0.51 27 13.17
43 0.60 29 11.47
45 0.78 30 6.67
48 0.67 32 10.67
51 0.69 34 10.67
54 0.81 36 6.67
55 0.55 37 16.82
58 0.79 39 8.07
59 0.56 39 17.19
62 0.90 41 3.97
63 0.70 42 12.67
67 0.94 45 2.69
68 0.76 45 10.59
69 0.59 46 18.67
73 0.96 49 2.01
74 0.81 49 9.27
75 0.67 50 16.67
76 0.53 51 24.16
81 0.88 54 6.67
82 0.76 55 13.41
83 0.64 56 20.24
84 0.52 56 26.67
89 0.99 60 0.67
90 0.89 60 6.67
91 0.79 61 12.74
92 0.70 62 18.87
93 0.60 62 24.67
94 0.51 63 30.83
101 0.92 68 5.39
102 0.84 68 10.67
103 0.77 69 16.08
104 0.69 70 21.54
105 0.62 70 26.67
106 0.55 71 32.15
115 0.96 77 3.35
116 0.90 78 8.07
117 0.84 78 12.67
118 0.78 79 17.41
119 0.72 80 22.18
120 0.67 81 27.00
121 0.61 81 31.46
122 0.56 82 36.30
123 0.50 83 41.16
134 0.97 90 2.69
135 0.93 91 6.74
136 0.88 91 10.71
137 0.84 92 14.77
138 0.80 93 18.87
139 0.76 93 22.75
140 0.71 94 26.86
141 0.67 95 30.99
142 0.63 95 34.79
143 0.59 96 38.94
144 0.56 97 43.11
145 0.52 97 46.83
161 0.97 108 3.35
162 0.94 109 6.73
163 0.91 110 10.12
164 0.88 110 13.41
165 0.85 111 16.82
166 0.82 112 20.24
167 0.79 112 23.47
168 0.76 113 26.90
169 0.73 114 30.36
170 0.71 114 33.53
171 0.68 115 36.99
172 0.65 116 40.47
173 0.62 116 43.58
174 0.60 117 47.07
175 0.57 118 50.57
176 0.55 118 53.64
177 0.52 119 57.15

The C++ code to generate the above table is

code:


#include <stdio.H>

int main(int argc, char* argv[])
{
for( int i=20; i<300; i++ )
{
double f = 800.0 / i;
int ipart = (int)f;
double fpart = f - ipart;

if( fpart > 0.5f )
{
printf( "%3d %.2f %3d %6.2f\n", i, fpart, (int)(i * .675), (1.0-fpart) * (int)(i*.675) );
}
}

return 0;
}

Matching our conditions with the table, we predict that the best frame rates would be about 29, 41, 83, 92, 120, 140, and 170. Notice that these numbers are very near the values that people have found experimentally. This match between theory and experience lends credence to the model used.

Now, on to the mod I wrote. Here are some in-game screenshots at various frame rates:











When you jump, you are given 270 units / second of upward velocity, with a gravity of 800 units / second squared. Basic physics tells us that you should reach a maximum height of 45.5625 units after 0.3375 seconds. The height value shows the actual height of your jump. Frames is the number of frames the server used in reaching that height. Extra Vel is the approximate additional velocity you gained from rounding errors. Extra Hgt is the approximate additional height you gained from rounding errors.

Lastly, here is the mod I used to get the above results. You can use it to optimize your frame rate for maximum jumping height / distance.

Any questions?

EDIT: forgot to properly close the UBB italics tag

[This message has been edited by Coriolis (edited 08-21-2000).]

;----Copied from Guwgl
100 hz / 100 fps / 100 maxpackets
"83 FPS , 85 maxpackets & 85hZ refresh

or

83 FPS , 100 maxpackets & 85hZ refresh"

both are the same since you will send 83 packets anyway.
You should use that, unless it gives you a bad aim feeling.

And zongo isn't available @ 10 am.
et 100fps 100 packets

cpma 125fps 125packets

displayrefresh as high as your monitor is able to run


<3 iiyama vision master pro 454
[img|left]http://hitech-online.ru/bank/articles/_1480.jpg[/img]

/com_maxfps "125"
/sensitivity "0.6"
/cl_maxpackets "40"
/r_mode "-1"
/r_customwidth "1440"
/r_customheight "900"
/r_dipslayrefresh "75"

EDIT: mouse with wire
cl_maxpackets "40"

r_mode "8"

com_maxfps "142"

sensitivity "1"

r_displayrefresh "75" @ SyncMaster930BF <-- LCD

mx518@500hz+patch-no-mouseacell

and YES, this is MADNESS ! :)))
no .. this is XFIRE :D
Parent
well nice topic : > I Miust ask :

which should I use 100 fps or 125 fps if im playing :

r_mode 6 100 packets and 100 hz
r_mode 4
maxfps 125
maxpackets 100
85hz

logitech g1
windows 4/11
game sens 3.25

noaccel patch/fix
Back to top