Post by Xarious on Mar 14, 2017 21:43:53 GMT -5
So, I wanted to archive a bit of information on this topic specifically that seemed useful for future server hosts. I've pulled this directly from the JKHub forum. It was originally posted by Raz0r, who is known for his extensive work on the JA+ mod and coding in general.
Original source can be found here: jkhub.org/topic/5277-sv-fps-com-maxfps-explanation/#entry78065
The correlation between snaps and sv_fps is that each server frame (happens every 1000/sv_fps times per second) a snapshot is generated.
Using a snaps value higher than the sv_fps has no effect, so when you're using snaps 40 on a sv_fps 20 server, you'll get 20 snapshots/second. When you move to a sv_fps 40 server, you'll recieve 40 snapshots/second.
A snapshot contains things like positional and state information (what weapon an entity has, etc). The more frequent the snapshot updates are, the smoother you will see people move because you'll have more sample points to interpolate between.
Visualise this as if you mark a spot on the map twice per second as you're moving along. Other people only see those spots and position you between them based on how long it's been since the spot was placed. (i.e. spot 1 placed at 500ms, spot 2 placed at 1000ms. If they're at 1250ms, they'll attempt to predict where you are based on how far you could have moved at your current speed from spot 2, 250ms into the future)
Because frametimes are measured in milliseconds, sv_fps has the same limitation as com_maxFPS, where you can only reach certain frametimes/framerates.
There is an inherent link between framerate and frametime. Framerate being how many updates per second, and frametime being how long (in milliseconds) between each frame, so a framerate of 1000 means 1ms frametime. That is to say frametime = 1000(ms) / desired-framerate.
If you wanted a framerate of 30 (sv_fps) that would mean a frametime of >>> 1000.0 / 30 = 33.333333333333336
Because the frametime is stored in an integer, the game would update every 33ms, which means that every frame you're accumulating an error of .333msec. Every ~third frame (.333 * 3) you would potentially run two frames - the first having a 33ms frametime, the second having a 1ms frametime - or it could be a 34msec frametime.
The main issue here is that it's inconsistent. Remember what I said about each server frame generating a snapshot, and people guessing your position based on those snapshots.
If you had a consistent frametime like 25, 50 (sv_fps 40, 20) the snapshots would be at a consistently smooth rate.
An issue of using a "non-standard" framerate (i.e. not sv_fps 20) is that some calculations (e.g. applying saber damage with sv_fps 20) are not tied to the frametime, so they'll run consistently on every frame. This is the same issue that some games have (but at a smaller scale, where only some things are affected)
Another related issue is things that happen more frequently than 50msecs. This is noticeable in Quake where the LG hit sound should play more frequently, and you'll see the plasma bolts faster than on sv_fps 20.
Again, thanks to Raz0r for the unintended contribution!
Original source can be found here: jkhub.org/topic/5277-sv-fps-com-maxfps-explanation/#entry78065
The correlation between snaps and sv_fps is that each server frame (happens every 1000/sv_fps times per second) a snapshot is generated.
Using a snaps value higher than the sv_fps has no effect, so when you're using snaps 40 on a sv_fps 20 server, you'll get 20 snapshots/second. When you move to a sv_fps 40 server, you'll recieve 40 snapshots/second.
A snapshot contains things like positional and state information (what weapon an entity has, etc). The more frequent the snapshot updates are, the smoother you will see people move because you'll have more sample points to interpolate between.
Visualise this as if you mark a spot on the map twice per second as you're moving along. Other people only see those spots and position you between them based on how long it's been since the spot was placed. (i.e. spot 1 placed at 500ms, spot 2 placed at 1000ms. If they're at 1250ms, they'll attempt to predict where you are based on how far you could have moved at your current speed from spot 2, 250ms into the future)
Because frametimes are measured in milliseconds, sv_fps has the same limitation as com_maxFPS, where you can only reach certain frametimes/framerates.
There is an inherent link between framerate and frametime. Framerate being how many updates per second, and frametime being how long (in milliseconds) between each frame, so a framerate of 1000 means 1ms frametime. That is to say frametime = 1000(ms) / desired-framerate.
If you wanted a framerate of 30 (sv_fps) that would mean a frametime of >>> 1000.0 / 30 = 33.333333333333336
Because the frametime is stored in an integer, the game would update every 33ms, which means that every frame you're accumulating an error of .333msec. Every ~third frame (.333 * 3) you would potentially run two frames - the first having a 33ms frametime, the second having a 1ms frametime - or it could be a 34msec frametime.
The main issue here is that it's inconsistent. Remember what I said about each server frame generating a snapshot, and people guessing your position based on those snapshots.
If you had a consistent frametime like 25, 50 (sv_fps 40, 20) the snapshots would be at a consistently smooth rate.
An issue of using a "non-standard" framerate (i.e. not sv_fps 20) is that some calculations (e.g. applying saber damage with sv_fps 20) are not tied to the frametime, so they'll run consistently on every frame. This is the same issue that some games have (but at a smaller scale, where only some things are affected)
Another related issue is things that happen more frequently than 50msecs. This is noticeable in Quake where the LG hit sound should play more frequently, and you'll see the plasma bolts faster than on sv_fps 20.
Again, thanks to Raz0r for the unintended contribution!