yquake2/yquake2remaster
0
0
Fork 0
mirror of https://github.com/yquake2/yquake2remaster.git synced 2024-11-22 12:41:21 +00:00
Code Issues Projects Releases Packages Wiki Activity

doc/040_cvarlist.md: improve documentation of cl_async etc

Browse source 
to reflect reality, including the latest changes
This commit is contained in:
Daniel Gibson 2022-05-10 20:06:25 +02:00
parent 1833f160eb
commit e3aa1010f9
1 changed files with 42 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

57
doc/040_cvarlist.md
View file

@ -57,21 +57,43 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
time for the next frame. The later is more CPU friendly but rather
inaccurate, especially on Windows. Use with care.
* **cl_async**: If set to `1` (the default) the client is asynchronous.
The client framerate is fixed, the renderer framerate is variable.
This makes it possible to renderer as many frames as desired without
any physics and movement problems. The client framerate is controlled
by *cl_maxfps*, set to `60` by default. The renderer framerate is
controlled by *vid_maxfps*. There are two constraints:
* **cl_maxfps**: The approximate framerate for client/server ("packet")
frames if *cl_async* is `1`. If set to `-1` (the default), the engine
will choose a packet framerate appropriate for the render framerate.
See `cl_async` for more information.
* *vid_maxfps* must be the same or greater than *cl_maxfps*.
* In case that the vsync is active, *vid_maxfps* must not be lower
than the display refresh rate.
* **cl_async**: Run render frames independently of client/server frames.
If set to `0`, client, server (gamecode) and the renderer run synchronous,
(like Quake2 originally did) which means that for every rendered frame
a client- and server-frame is executed, which includes the gamecode and
physics/movement-simulation etc. At higher framerates (above 95 or so)
this leads to movement bugs, like being able to jump higher than expected
(kind of like the infamous Quake 3 125Hz bug).
For `cl_async 0`, *vid_maxfps* (or, if vsync is enabled, the display
refresh rate) is used and *cl_maxfps* is ignored.
Both constraints are enforced.
If *cl_async* is set to `1` (the default) the client is asynchronous,
which means that there can be multiple render frames between client-
and server-frames. This makes it possible to renderer as many frames
as desired without physics and movement problems.
The client framerate is controlled by *cl_maxfps*,
the renderer framerate is controlled by *vid_maxfps*.
If *cl_async* is set to `0` *vid_maxfps* is the same as *cl_maxfps*,
use *cl_maxfps* to set the framerate.
As client/server frames ("packet frames") are only run together with
a render frame, the *real* client/server framerate is always rounded to
a fraction of the renderframerate that's closest to *cl_maxfps*.
So if for example *vid_maxfps* is `60` and *cl_maxfps* is `50`, it will
be rounded to `60` and every renderframe is also a packet frame.
If *vid_maxfps* is `60` and *cl_maxfps* is `40`, it will be rounded to
`30` and every second render frame is also a packet frame.
It seems like the best working packet framerate is `60` (which means that
the render framerate should be a multiple of that), otherwise values
between `45` and `90` seem to work ok, lower and higher values can lead
to buggy movement, jittering and other issues.
Setting *cl_maxfps* to `-1` (the default since 8.02) will automatically
choose a packet framerate that's *both* a fraction of *vid_maxfps*
(or display refreshrate if vsync is on) *and* between 45 and 90.
* **cl_http_downloads**: Allow HTTP download. Set to `1` by default, set
to `0` to disable.
@ -340,12 +362,11 @@ it's `+set busywait 0` (setting the `busywait` cvar) and `-portable`
It's recommended to use the displays native resolution with the
fullscreen window, use `r_mode -2` to switch to it.
* **vid_maxfps**: The maximum framerate, if `cl_async` is `1`. Otherwise
`cl_maxfps` is used as maximum framerate. See `cl_async` description
above for more information. *Note* that vsync (`r_vsync`) also
restricts the framerate to the monitor refresh rate, so if vsync is
enabled, the game won't render more than frame than the display can
show.
* **vid_maxfps**: The maximum framerate. *Note* that vsync (`r_vsync`)
also restricts the framerate to the monitor refresh rate, so if vsync
is enabled, the game won't render more than frame than the display can
show. Defaults to `300`.
Related to this: *cl_maxfps* and *cl_async*.
* **vid_renderer**: Selects the renderer library. Possible options are
`gl1` (the default) for the old OpenGL 1.4 renderer, `gl3` for the