FRAMETIME: a Runtime Variable

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.

Benefits: Flexibility.

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 refresh).
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

Problems:

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

Feasibility: The current Q2 server and client are mostly set up for this already.

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.

Implementation:

GameDLL:

    In:      g_local.h
    change:  extern float FRAMETIME;
 
    In:      game.h::game_export_t
    add:     float        frametime;
   
    In:      g_main.c::GetGameAPI
    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.
```
    In: q_shared.h
    #define CS_FRAMETIME   6

    In: g_spawn.c::SP_worldspaw
    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.
```
     In:    config.cfg
     add:   set frames  10
    
```
The number of frames per second sets the smallest frametime acceptable.

Related Issues: 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 Internet, too.

The complementing "Client Side Entity Extrapolation" would remove all need to make the client aware of FRAMETIME. The goal is an entirely event driven client.

Submitted 980321, revised 980328, revised 980420, revised 980505, comments to Bernd Kreimeier.