Re-reading this over, I don't think I explained it quite well enough. It's
hard to explain in words, but if someone wants a better explanation, I can
do something in mspaint that would explain it.

TL;DR: There IS a difference between high and low FPS servers, but it does
not give a single player an advantage and is not really visually
"noticeable". The main reason people say they notice the difference, is
because of the hardware difference between most high and low FPS servers.

On Tue, Jul 5, 2011 at 9:26 PM, J M <[email protected]> wrote:

>   Well, the main reason that people feel like high FPS servers are
> "smoother" or "better" is because they're generally running on much better
> hardware and OS's. If a server can only reach a maximum server FPS of around
> 66, it is bound to dip below that. Server FPS is constantly fluctuating, and
> very quickly. A server that claims to be 1000 FPS or something is on
> powerful enough hardware, that if it does fluctuate, it is not likely to dip
> below 66.666... fps at all. Servers advertised as 250 FPS or 333 FPS or
> whatever are running on much weaker hardware, in general. And on this weaker
> hardware, it is much more likely that the server FPS will fluctuate below
> 66.666... So if you have a server running on top of the line hardware
> (including network hardware) and you limit it to 66 FPS (I would limit it to
> 67, actually) and the hardware is powerful enough to maintain it, then hit
> detection should not suffer at all.
>
> On the other hand, if you look at the way FPS and tick rate relate to each
> other, you can see that a server running at extremely high FPS would make a
> difference, though it wouldn't really be noticeable to the human eye. If the
> server runs a tick every 15 ms (thats 66.666... fps, which TF2 servers are
> locked to), and the FPS runs at a smooth 66 FPS, then a player's input can
> only be retrieved by the server once between every tick. A tick is when the
> world is calculated, a frame is when input can be received or sent.
> If I sent a message that says I shot and the frame has already run before
> the next tick occurs, then my message will not be incorporated into this
> next tick's calculation. It will be received by the next frame and
> incorporated into the tick after that. If the server FPS is much higher,
> then my message might be received and incorporated into the first tick,
> because there are 10 more frames to go before the next tick occurs and it
> will be received by one of those frames instead of having to wait for the
> next frame. It's really down to single milliseconds and there would be
> noticeable and visually explainable difference, but many players say they
> can "feel" the difference. I agree, to some extent, but I definitely think
> Valve needs to rework the tick and FPS system they have with servers.
>
> On Tue, Jul 5, 2011 at 7:12 PM, Saul Rennison <[email protected]>wrote:
>
>> But ticks occur inside a frame, so if you have a constant FPS of 66, you
>> will also have a constant tick rate of 66. It makes no logical sense that
>> doing more frames in a second is useful, because no ticks will occur in
>> them. Hence, there is no change in hit detection, because no more network
>> updates are sent out, or no more client->server move packets are processed,
>> so the world doesn't change whatsoever between ticks/frames.
>>
>> A Valve employee could prove me wrong here but the proof is all in the
>> Quake/Source Engine leak source code.
>>
>> --
>> Kind regards,
>> *Saul Rennison*
>>
>>
>>
>> On 5 July 2011 17:15, Mart-Jan Reeuwijk <[email protected]> wrote:
>>
>>> fps_max <> server tick rate
>>>
>>> ------------------------------
>>> *From:* AnAkIn . <[email protected]>
>>> *To:* [email protected]; Half-Life dedicated Win32 server mailing list <
>>> [email protected]>
>>> *Sent:* Tuesday, 5 July 2011, 17:25
>>> *Subject:* Re: [hlds] Lower server-side FPS with recent updates?
>>>
>>> It's just because fps_max doesn't set the fps limit correctly on the
>>> servers. If you put it on 100 you'll end up having 64 fps, etc.
>>> If fps_max would work correctly and you would get a constant 66 fps, then
>>> it's pointless to have anything above that.
>>>
>>> 2011/7/5 TRISTAN MARLER <[email protected]>
>>>
>>> If you run fps_max 66 your hit detection will suffer. I've competed on
>>> servers which were 200ish compared to a 1000fps server and noticed a
>>> measurable difference in hit detection, both on the opponent and rocket
>>> jumping. However over 1000fps has no bonus as far as I can tell. However, 66
>>> fps server side limit is grossly short. I recommend against this completely.
>>>
>>>
>>> -BloodyIron
>>>
>>>
>>> ----- Original Message -----
>>> From: Joseph Wu <[email protected]>
>>> Date: Tuesday, July 5, 2011 12:58 am
>>> Subject: [hlds]  Lower server-side FPS with recent updates?
>>> To: [email protected]
>>>
>>> > Yes. They changed the code in SRCDS to lower idle cpu usage.
>>> >
>>> > First you want to check if HPET is enabled on your server box.
>>> > And then run
>>> > your servers with the fps_max at 500 thus you should be able to
>>> > get a
>>> > semi-stable 500FPS. But valve and I highly recommend you running your
>>> > servers at the native 66fps/tick which is fps_max 66
>>> >
>>> >
>>> > _______________________________________________
>>> > To unsubscribe, edit your list preferences, or view the list
>>> > archives, please visit:
>>> > http://list.valvesoftware.com/mailman/listinfo/hlds
>>> >
>>>
>>> _______________________________________________
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlds
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> AnAkIn,
>>> -------------
>>> ESL EU TF2 Admin
>>> http://www.esl.eu/eu/tf2
>>>
>>>
>>> _______________________________________________
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlds
>>>
>>>
>>>
>>> _______________________________________________
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlds
>>>
>>>
>>
>> _______________________________________________
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlds
>>
>>
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds

Reply via email to