I'm sure I miss some stuff quite often, we're all human. And, well, from the description Alfred just gave for server fps and from reading the Source netcode description page and associating the two, generating packets to send to clients and the rate that packets get sent at seem to have absolutely nothing to do with server fps and everything to do with tickrate. **Alfred just said that server fps does not change the game simulation.** The server doesn't send packets out for each server 'frame', it sends packets out after each tick, containing the data calculated for that tick. Every tick is a seperate moment in time, a seperate state of the game, a gamestate. Got a default 33 tickrate server, you get 33 seperate gamestates per second, no more, (and CPU not being a hinderance) no less. You just stated that a 500fps server will give you 500 updates per second, when clearly this is not the case. I also don't know why you're talking about client-side rendering interpolation, that has nothing to do with the server fps we're talking about. I think the fact that it has been called server "fps" is a little confusing, since we measure our graphics performance by this same term, "fps." But the two aren't nearly the same thing. Client-side interpolation only serves to smooth out your view between server ticks, it's got nothing to do with the server. If your computer can give you 66fps and you're playing on a 33 tickrate server then you get one interpolated frame for every 'real' frame. The server is still only generating 33 seperate gamestates. Client-side interpolation is part of the whole seperation of netcode and graphics. If your computer's beefy enough to render graphics at a much faster rate than the server is generating seperate gamestates, well, no reason it shouldn't give you as smooth an experience as possible. But it does so by making up its own data that has nothing to do with the server's data, other than the fact that it is using the server's seperate moments in time to form its guess at what goes inbetween the server's moments in time. The server still only deals with its own rate of simulation. If there is any benefit to the server being able to process input faster than it is simulating the gameworld, I'm not sure I see what that might be. If it only simulates the gameworld 33 times a second, why would it need to process player input at a rate any faster than that? As long as it is capable of processing that input fast enough to feed the next simulation step, you're golden. It's not a continuously changing world like our world is. It is a world based on completely seperate instances in time, coming at a fixed rate, but each one a representation of the world only at that instant. It is not a continuous, uninterrupted flow of time. Being able to process more input data than there are simulation steps shouldn't mean anything, since it is still only those simulation steps that make up the world.
On 8/8/05, James Tucker <[EMAIL PROTECTED]> wrote: > Clayton, honestly sir for someone with quite a good knowledge of the > source engine you do sometimes miss some really important stuff.... > > You will ALWAYS gain an advantage LOWERING LATENCY by increasing the > server (and client) side FPS. No, this does not increase the tick rate > you are correct, and again, it is correct that it doesn't change teh > rate of gameworld simulation - IT DOES CHANGE THE TIME TO PROCESS > PACKET AND THE TIME TO NEXT PACKET GENERATION - READ: LATENCY. > > Quick example: > > @500fps > packet arrives at server at 0ms > next frame comes in a max of 0.002 seconds > frame takes 0.002 seconds > packet put in outbound queue at t= 0.004s. > Server processing latency: 0.004s. > (update rate and rate also put limits on this, however you will see > that there is an optimal, but it's not at the tickrate). > > @33fps > packet arrives again at 0ms > next frame comes in a max of 0.033s > frame takes 0.033s seconds > packet put in queue at t=0.066 > Server processing latency: 0.066s. > > N.B. that at 33fps the server is starting to approach several of the > source netcode latency limits already - and this is without RTT or > DTT's completed. Yes there are adjustments made for this, however we > haven't as I said, hit any networking yet. > > Remember too that a frame doesn't necessarily process the next tick! A > frame can process any tick back to a maximum of the largest clients > cl_interp (or it's cap). -- Clayton Macleod _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
