Jump to content

Recommended Posts

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.

 

Did I miss anything? I only skimmed over the post.

Hugo, ent, Agent Jones and 2 others like this
Link to comment

so for us stupid people => it would be 40 sv_fps with clients having snaps 40 and com_maxfps 125 for smoothest gameplay experience?

 

its more demanding for the CPU at sv_fps 40 then 30, and i understand what u wrote about 30 not being as consistent but is it really that noticable despite it not being consistent? i tried flipping 30 and 40 but just what exactly is the difference? i cant tell for the life of me during a ton of duels and such so i just settled for 30...

Link to comment

so for us stupid people => it would be 40 sv_fps with clients having snaps 40 and com_maxfps 125 for smoothest gameplay experience?

 

its more demanding for the CPU at sv_fps 40 then 30, and i understand what u wrote about 30 not being as consistent but is it really that noticable despite it not being consistent? i tried flipping 30 and 40 but just what exactly is the difference? i cant tell for the life of me during a ton of duels and such so i just settled for 30...

With modern machines you probably won't notice a difference.

JKG Developer

Link to comment
  • 10 months later...

I have to say that back in the olden times before we knew much about this stuff and were trying to fix the bugs with JA's horribly bad saber collision, we found sv_fps 30 to be the best setting for JA+ mod MP settings...our logic then was that since JA was developed with the XBox360 in mind and XBox 360 had a max fps of around 30, it made sense. Obviously Raz0r's explanation makes far more sense.....but I have tested both settings for years, and it seems as though when set to sv_fps 40 there are a lot of unexpected extra collisions when the ghoul saber trace cvar is turned on when running JA+ with the MP damages, whereas 30 seems to eliminate the ghosting and the false hits. Maybe this has to do with the increased saber radius used when the MP damage cvar is set? I imagine what is more likely actually happening is that the hits aren't false, but that the client is correcting a frame that was predicted wrong...how does ping factor into sv_fps and snaps? Obviously at near 0 ping, I think the likelihood is that sv_fps of 40 would be the most accurate means of boosting the hit detection without sacrificing consistency; however, in practice, if sv_fps 40 generates far more inconsistency as far as JA+ mod is concerned (for base, sv_fps 40 does indeed seem perfect) would that have something to do with the networking? I also don't want to be thought crazy, but I did once find that when messing with higher sv_fps on one version of JA+ that the speed did indeed increase as I raised the values (although I don't think that happens anymore in build 7, I think it was beta 1 or build 4)...no this wasn't psychosomatic, because when I raised it up to 100 it was like a Roadrunner cartoon. I couldn't tell you why any of this is, because JA+ is shrouded in mystery that only Slider and his team understood and was developed without access to the source code and with I imagine somewhat limited knowledge of all the secrets buried in Q3 (though I could be wrong, for all I know he could have been a Q3 modder as well). Also, I've had people debate com_maxfps of 100 and 125 as being "best" in particular for strafe jumping. I honestly don't know which makes any sense, though on my laptop with OpenJK and the openGL replacer running I cap at about 30 like I'm on Xbox360 so I wouldn't know the difference.  :)

 

Edit:  Also, yes I know this is an old post that I'm resurrecting. But it's because I have always really been curious about this whole sv_fps thing.

Link to comment

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.

Hello,

 

thanks for these explanations.

Do the sv_fps influence the g_forceregentime ? I mean : if the sv_fps = 30 (so frametime = 33.33ms => 33ms) and g_forceregentime = 150, there will be no match between the two (33*4 = 132; 33*5 = 165).

Is there a difference for the force regeneration between a sv_fps 30 (which doen't match the force regen frames) and a sv_fps 40 (which match the force regen frames) ?

Link to comment

 

 

The same question stands for for com_maxfps (125, 333)

 

+/- why is openjk set to 40 as default?

+/- how does this differ in known modifications?

 

90 fps is the best for racing by far. You won't jump quite as far but as far as raw speed go with 90. A close second would be 142 I believe.

Smoo likes this
Link to comment

sv_fps controls the framerate at which the server runs. Generally at a higher framerate you can expect the following:

- More damage from force lightning, since this damage is run every frame

- Differences in sabering. More "precise" blocking and so forth.

- (possibly) more lag on slower servers

- probably more differences, depending on server setup, mods, etc. There are probably some physics changes that are fixed with openjk

 

I can't claim to know all the differences, because I have never really messed with sv_fps all that much. It's the serverside framerate, at any rate.

 

com_maxfps is the maximum fps that the client can reach. You won't see a difference past 90 or so on most monitors, because the changes are simply not able to be shown. I'd suggest keeping this no higher than about 125 unless you're doing benchmarking, simply because you are wasting your computer's power otherwise.

Smoo likes this
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...