Stih server lag mean those red "towers" when server has 45 players. I wouldn't say that's because my pc.

Ok, i'll try to put it on 60 FPS (yes i can see it in my monitor setup) at 1280x1024 with vsync.

_________________

I paid some attention to fps today, it was up to 70 occasionally, but often below 40 for some short period of time. Usually between 40 and 60.

I don't have always all 12 workspaces full, but very often, (i.e. whenever I'm having problems compiling something) I tend to open up dozens of windows (terminals, nautiluses, galeon (web browser), gedit, synaptic, etc. etc.) so I quickly run out of space.

Normally, it's only 5-6 of them having windows all over them.

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

hm i got a geforce 9500 gti and i dont have any ejaculatio praecox

_________________

9500 GTi... sounds like a car...

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

hihi, turbo.

_________________

MAP TOPIC:
suburbs is a badly compiled map, something fucked up in the process.
elgin has the same story, but not as bad as suburbs.


FPS STUFF:
setting maxfps to 120 is the same as if you set it to 125... doesnt matter.
it always tries to reach the nearest "1000 divided by non-point value-number".
i.e.
1000/2=500
1000/3=333
1000/4=250
1000/5=200
1000/6=167
1000/7=142
1000/8=125
1000/9=111
1000/10=100
1000/11=90
1000/12=83
.
.
.
333 and above does not work, it will make your client crash... or was it 250?
since i never reached numbers this high i did not get the information fixed into my memory, i just can tell you this will happen. wurst knows it IIRC?

maxfps and maxpackets correlate, and this is where the "1000 divided" comes from.
1000 stands for 1000ms=1s, and maxpacks should be an "even divisor" of maxfps.

this is where the 30/42 limit the urt-engine has for the maxpacks comes from...
30*4=120
42*3=126

so if you have maxfps 125 (or 120 for that matter) maximum every 3 or at least every 4 fps shown locally on your screen you get an update for the shown stuff from the server, forcing people to have more similar opportunities with the limit. (two people fighting each other, with one on very low and one with very high maxpackets will favour the one with the higher number clearly, game will feel much easier for him, and it is likely that they will see each other warp.)
because:
imagine a snapshot receiving you every 3.5 or 2.5 fps leads to rounding errors and wrong predictions.

there is a reason why consistency is the magical thing.

so far for the theory...
in urt your fps drop like they want, 120 to 60 and back being easily possible, leading the system i described before ad absurdum.


further on this frames/fps discussion... when i get the time i will write another essay on it that covers most of the stuff.

stuff i described in the post before covers the network related issues.
problem is all this correlates, and almost nobody really has a clue on what is going on. even after all the years i investigated on the topic, my knowledge is quite limited, i dont even know for sure if the stuff i write is valid or not. it just happens to be the only explanation making sense...

so here goes another episode of "MCQUEEN ON URBAN TERROR"

on the question of fps ingame and hz of your monitor...
it is similar to the stuff i described in the post i just did before... the better the both things "match", the less rounding errors you get, the more everything is shown accurately on your screen.
i.e. you get the idea why it is better to have a non-decimal multiplicator for the hz/fps relation?
this may be just theory, and in urt all this sucks anyway because of the fps drops. (that are REALLY fucking stuff up, no matter who claims anything otherwise.)

vertical sync can be forced via control panel and gfx settings or via game engine. i dont know the difference between both out of the box, but turning it on basically forces your monitor to syncronize its hz to fps (or the other way round? maybe that is the difference between ingame and control panel setting... hmmmm).
this means one has to wait for the other somehow...
if all works as expected, it is awesome.
if it doesnt, you have tearing, input lag, fps drops, fucky problems.

if you once have experienced how good all can work (like i did in my cpma days when my comp was able to do so), you will be absolutely stunned.
even if you ping like 5 ms to the server already, you still will really FEEL the improvement. i was able to tell all the differences in cpma.

and this is why i am such a performance nazi on train.
another thing backing up all this is blinky's "trainbot" (=why he has so much better hits compared to all the other maps). or why most people have much much better hits at night (when the server is not a populated, and network usage is lower, although network usage is not as bad an issue as it is the fps drops from what i got over time from experiences.)

bottom line:
as urt has fps drops like hell, no matter what comp you are on, it will never play as good as it could, which is quite sad.
performance is the only real problem of urban terror, and most of the "HITZZZ" issues will clear i bet, once code is cleared and stuff is solved.

dont believe me? load up an urt map in q3, and you will have much better frames.

Thanks for the posts steve, I was totally forgiving FPS/MaxP relation when I advised to use vsync whenever you can. I did some further research about it, which is cool because I finally found the explanation for the 125fps bug in Q3, 8 years after I knew about the value o/ (http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html - oops post from 2001, I was using 56K at that time...)

If I may add about vsync : most of first person shooter (I didn't use "FPS" there...) use 2 graphic buffers do display frames on screen : one where image is actually being rendered (back), the other being displayed on the screen (front).
When vsync is on, the graphic card "waits" for the next frame to be completely rendered into the back buffer and wait for the right moment to display the next frame (according to the monitor's refresh rate), then swap the two buffers : the screen displays the buffer containing the new frame while the next frame is being rendered by the engine into the other.
When vsync is off, the GC doesn't wait before swapping, it just swaps the buffer when the next frame is complete, so the current frame is partially filled with a piece of the next frame, that's the tearing effect. http://en.wikipedia.org/wiki/Page_tearing or better that video http://www.youtube.com/watch?v=aQXppnkj2qY, it's an advertising but it's exactly what I see when I have 100 FPS on my 60Hz monitor =).
Main drawback with vsync : if FPS < refresh rate, the GC has to wait 1 cycle more for the next frame to render so it skips displaying a frame, giving an even more choppy game. That's why people often having framedrop below refresh rate shouldn't use vsync. Hum I often have framedrop below RR and I use vsync, seems it was more obvious when I played Q3, maybe because I was using a CRT then...

About the network, I found an excel file to calculate actual number of packets sent when taking in account current FPS and cl_maxpackets value (http://quaddenied.free.fr/insideq3a.htm - /! warning, some text in french on the webpage). I guess the formula is not 100% accurate (seems the 0.1 value is arbitrarily chosen), but I used it in excel to see the relation between actual framerate and cl_maxpackets value (attached gif : cl_maxpackets in X, FPS in Y, outgoing packets actually sent as results). Have a look at the result : imagine you have cl_maxpackets = 42, com_maxfps = 125, if a framedrop occurs and lower your framerate to 90 FPS which is still quite good, you get a decrease of 28% of packets sent compared to the number of packets which *should* be sent oO !

About the cfg, I use vsync so 63 FPS max and cl_maxpackets 42. So I shouldn't send more than 32 packets/s... it totally matches the result I got when I sniffed the outgoing traffic from my UrT :/ Fortunately, when I got framedrops to 45 FPS, I have full outgoing packets to compensate the bad framerate =)
To Ana if you read this : you told me you quite unhit these days, actually it seems to correspond to the time I sent you my cfg, that *may* be the explanation... sooooorrryyyyyyyy

_________________
ut4_he_tennis_v0.1
-------------------------
"We are talking about computers here, compared to those I can read women like a book ;P"
Unclefragger

now as several people work on singular topics we will now get a deep-seating need for a working wiki section at dswp.de ...

Totally

_________________
ut4_he_tennis_v0.1
-------------------------
"We are talking about computers here, compared to those I can read women like a book ;P"
Unclefragger