Advertisement
Page 1 of 1
[Suggestion] Wierd Behavior Of The Engine - Snaps/S - Perhaps Important
#1
Posted 20 November 2009 - 01:17 AM
this is related to sv_fps (snaps / second)
I'm playing around trying to add a "snaps per second" meter in an .exe build (linked on my sig, not yet in) and I found the following peculiar - and worrying behavior:
server snaps 20: (urt default and locked)
SPS (snaps/second from server -> to client) jumps from 20 to 19 all the time. 19 is a common mean. The common deviation from the mean ('standard deviation') is 2-3 snaps / second.
the trend continues with other values, e.g. 40:
and then - surprise - there are "magic values":
on 125:
solid, 0 deviation
a more realistic approach, 25:
again, solid, 0 deviation.
I may have a version of the .exe soon for anyone to test. Though a developer can just make his own meter i suppose.
(the images are from baseq3 but same deviation was shown on urt on 20)
edit:
Ignore the 0 columns (2nd column of 10s interval), it's not ready yet so it printed nothing.
I suspect it may be better for gameplay to use one of those magic values e.g. 25, it also reduces gameplay latency and needs some more resources but it may be worth it nowadays provided there are no bugs because of it as it has been discussed before.
update: this behavior appears to be related to FPS of the client, as it should have been obvious, however since most clients are going to be playing on a certain FPS anyway, certain sv_fps values might be more optimal relating to this behavior, regardless of the latency output due to their number.
I'm playing around trying to add a "snaps per second" meter in an .exe build (linked on my sig, not yet in) and I found the following peculiar - and worrying behavior:
server snaps 20: (urt default and locked)
SPS (snaps/second from server -> to client) jumps from 20 to 19 all the time. 19 is a common mean. The common deviation from the mean ('standard deviation') is 2-3 snaps / second.
the trend continues with other values, e.g. 40:
and then - surprise - there are "magic values":
on 125:
solid, 0 deviation
a more realistic approach, 25:
again, solid, 0 deviation.
I may have a version of the .exe soon for anyone to test. Though a developer can just make his own meter i suppose.
(the images are from baseq3 but same deviation was shown on urt on 20)
edit:
Ignore the 0 columns (2nd column of 10s interval), it's not ready yet so it printed nothing.
I suspect it may be better for gameplay to use one of those magic values e.g. 25, it also reduces gameplay latency and needs some more resources but it may be worth it nowadays provided there are no bugs because of it as it has been discussed before.
update: this behavior appears to be related to FPS of the client, as it should have been obvious, however since most clients are going to be playing on a certain FPS anyway, certain sv_fps values might be more optimal relating to this behavior, regardless of the latency output due to their number.
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#2
Posted 20 November 2009 - 03:11 AM
ok i released this meter in the relevant thread http://forums.urbant...n-urt-directly/
for anyone to see.
tests remember are done on baseq3 for other numbers, 20 can be also shown on urt.
for anyone to see.
tests remember are done on baseq3 for other numbers, 20 can be also shown on urt.
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#4
Posted 20 November 2009 - 01:26 PM
it doesn't matter what the map is for this behavior.
it's probably q3dm0.
it's probably q3dm0.
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
Advertisement
#6
Posted 22 November 2009 - 08:31 PM
Well Cooked Nade Burgers, on 22 November 2009 - 08:27 PM, said:
it was suggested to increase/unlock sv_snaps for 4.2
the question is will the devs listen
the question is will the devs listen
this might be important; if a more stable number is better for gameplay it might be better to at least lock it to another value, say 25.
I've also made an entry at the bug tracker on ioq3 in case anyone notices it.
edit: and maybe investigate it more.
This post has been edited by mitsubishi: 23 November 2009 - 03:17 PM
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#7
Posted 02 December 2009 - 02:39 PM
I have news on this; apparently this is affected by the FPS of the client as it should have been obvious. e.g. a client on 20 FPS - which is unplayable but for the testing - appears to produce no such deviations.
Also, another "cryptic" piece of info is available. The server sends snaps in a fashion and the client deems them to be treated as "extrapolated" or not. This is apparently not the same kind of extrapolation shown on the net meter (as yellow) which appears to be dealt by game code there; this appears to be a more lower level indication (recorded on cl.extrapolatedsnapshot).
the new meter here shows the rate of that kind of extrapolation.
What is interesting is that this kind of extrapolation occurs always, even on local devmap and it goes away on certain sv_fps values, e.g. 125. In other values it appears to be extremely unstable, e.g. on sv_fps 80.
(all tests on baseq3 which allows changing of the vars)
Also, another "cryptic" piece of info is available. The server sends snaps in a fashion and the client deems them to be treated as "extrapolated" or not. This is apparently not the same kind of extrapolation shown on the net meter (as yellow) which appears to be dealt by game code there; this appears to be a more lower level indication (recorded on cl.extrapolatedsnapshot).
the new meter here shows the rate of that kind of extrapolation.
What is interesting is that this kind of extrapolation occurs always, even on local devmap and it goes away on certain sv_fps values, e.g. 125. In other values it appears to be extremely unstable, e.g. on sv_fps 80.
(all tests on baseq3 which allows changing of the vars)
This post has been edited by mitsubishi: 02 December 2009 - 02:41 PM
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
#9
Posted 04 December 2009 - 10:18 AM
ok though most of the behavior appears to be there on remotely.
btw, as mentioned in the 'latency' thread, if sv_fps '25' appears to be a more stable value to clients (per the 1st post here) why not be able to use it.
btw, as mentioned in the 'latency' thread, if sv_fps '25' appears to be a more stable value to clients (per the 1st post here) why not be able to use it.
This post has been edited by mitsubishi: 04 December 2009 - 10:40 AM
- Optimized exe; builds of ioq3 engine for urt With GoogleTranslate, Bumpy, dmaHD, iKALiZER, Raw Mouse, Bug Fixes, ..
- Networking, lag meter, and gaming consistency guide
Page 1 of 1