FRAMETIME A Runtime Variable
FRAMETIME currently fixing the server to 10Hz refresh
is made a runtime variable. Server and Game DLL share
this value, the client is either event driven and
scales all client side effects by wall clock time,
or gets knowledge of the value on each change.
- a single player 2 Voodoo2 SLI setup could be run
to match screen refresh better (tests show that
Q2 performance is not optimal at 120fps screen
- with a 100 MBit dedicated LAN, 2 Voodoo2
in SLI mode, and a high end dedicated server a server
refresh at 20Hz or more is a better match for a screen
refresh of 60Hz or more (e.g. LBE).
- if a mod needs to work around the client builtin
prediction of player movements completely,
a 20Hz server refresh is more likely to be
perceived as smooth
- if a mod needs complete custom inputs, and has
to process all inputs on the server (again
circumventing prediction), roundtrip latency
for response on user input is smaller
- additional user confusion (one more configuration variable)
- performance penalty (access of a runtime variable instead
of an immediate value)
- currently even at 20Hz not playable on Internet
The current Q2 server and client are mostly set up for
- Test have run a dedicated Q2 server for multiplayer
in timedemo 1 mode on a 100Mbit LAN, which
basically makes the server to go as fast as it can.
It floods the LAN, but play is possible. Certain
effects either client side, or server side, or within
the GameDLL use the value of FRAMETIME, though.
- Running a dedicated Q2 server with timescale 2
gives you a 20 Hz update rate now (some artifacts as
mentioned above). This reportedly leads to disconnects
even on ISDN-to-Internet, so there won't be much gain
for Internet play.
change: extern float FRAMETIME;
add: float frametime;
add: globals.frametime = FRAMETIME;
There might be some fixes, if the global FRAMETIME
define is not used consistently, but a grep for
magic 0.1 does not look bad.
- Q2 Client: FRAMETIME knowledge will have to be removed
from the client. The client has to use system clock
time to e.g. do EF effects properly (e.g. EF_ROTATE).
The client is already event-driven, but FRAMETIME is
used in several places, including client side
interpolation of entity position updates.
The client source is n./a. for more detailed discussion.
- Q2 Server: the RunFrame calls will have to
be timed at FRAMETIME. The existing implementation
for timedemo/timescale could be used.
If the server uses globals.frametime directly, or
copies it within the loop, the value could be adjusted
dynamically by the DLL. If the server writes to
globals.frametime, the server could adjust the value
dynmically according to ping.
The server source is n./a. for more detailed discussion.
- Network protocol: if the client uses FRAMETIME
explicitely, or for user preferences, an extension of
the network/configuration protocol is needed.
#define CS_FRAMETIME 6
gi.configstring (CS_FRAMETIME, va("%f", globals.frametime) );
Note that this prohibits runtime changes if a configstring
change is not transferred to the client,
or not processed at the client, e.g. during a game.
FRAMETIME will at least be set by the DLL (per game). It
could also be set by server console command, or changed
at runtime by both server and DLL.
- User preferences. The user needs a configuration variable
to keep the client from disconnecting on high traffic
servers. Mandatory for internet play.
add: set frames 10
The number of frames per second sets the smallest
This partly competes with more involved proposals regarding
client side GUI modification or client side prediction.
The latter have the advantage of working with the
The complementing "Client Side Entity Extrapolation"
would remove all need to make the client aware of
FRAMETIME. The goal is an entirely event driven
Submitted 980321, revised 980328, revised 980420,
comments to Bernd Kreimeier.