Remove 0.95 factor for packet framerate

It could make things stutter, especially if cl_maxfps was deliberately
set to a fraction of the display refreshrate (as it'd target a few
frames less).
The 0.95 factor was supposed to ensure that we don't have more packet
frames than renderframes (or two packet frames in a row without
rendering in between), as that apparently breaks the movement prediction
code. We now ensure the same thing my not running a packet frame if no
render frame is run at the same time.
This commit is contained in:
Daniel Gibson 2022-05-08 18:10:25 +02:00
parent ab8d700674
commit 5a8382064a
1 changed files with 9 additions and 6 deletions

View File

@ -562,11 +562,8 @@ Qcommon_Frame(int usec)
rfps = (int)vid_maxfps->value;
}
/* The target render frame rate may be too high. The current
scene may be more complex then the previous one and SDL
may give us a 1 or 2 frames too low display refresh rate.
Add a security magin of 5%, e.g. 60fps * 0.95 = 57fps. */
pfps = (cl_maxfps->value > (rfps * 0.95)) ? floor(rfps * 0.95) : cl_maxfps->value;
// we can't have more packet frames than render frames, so limit pfps to rfps
pfps = (cl_maxfps->value > rfps) ? rfps : cl_maxfps->value;
// Calculate timings.
@ -581,7 +578,7 @@ Qcommon_Frame(int usec)
{
if (R_IsVSyncActive())
{
// Netwwork frames.
// Network frames.
if (packetdelta < (0.8 * (1000000.0f / pfps)))
{
packetframe = false;
@ -607,6 +604,12 @@ Qcommon_Frame(int usec)
renderframe = false;
}
}
if (!renderframe)
{
// we must have at least one render frame between two packet frames
// => no packet frame without render frame
packetframe = false;
}
}
else
{