mirror of
https://github.com/yquake2/yquake2remaster.git
synced 2025-01-18 23:41:38 +00:00
Bump cl_maxfps to 60.
Yesterday I chose setting cl_async to 0 since I saw some movement
changed with the async client enabled. Especially when clipping against
bevels the game started to stutter and there were small rendering
problems. After some debugging I realized that it is caused by slight
inaccuracies in the move prediction. When cl_maxfps is too low, the
movement error between two render frames becomes to big, leading to
misspositions. There're two ways to solve this problem:
* Processing more client frames. Most async clients I've looked on
process 60 or even 90 render frames. I chose to stay at 60 since
I was unable to see differences with higher rates.
* Changed to pmove.c and the pmove_t struct. Some multiplayer focused
clients go that way. But there's a very high of breaking singleplayer
movement and pmove_t is part of the server <-> game API. Additionally
the network code must / should be altered. So this is unsuitable for
YQ2.
Please note that there's still a change in movement. Before 4ae8706
and
when cl_async is set to 0 movement is dependend on the render framerate.
At low framerate bevel clipping isn't working too good, at high
framerates prediction causes physics changes like the famous 125hz bug.
With cl_async set to 1 the network framerate is stable, leading to a
more consistant behahiour.
This commit is contained in:
parent
070d94ec77
commit
d6136cbba5
1 changed files with 1 additions and 1 deletions
|
@ -484,7 +484,7 @@ CL_InitLocal(void)
|
|||
cl_footsteps = Cvar_Get("cl_footsteps", "1", 0);
|
||||
cl_noskins = Cvar_Get("cl_noskins", "0", 0);
|
||||
cl_predict = Cvar_Get("cl_predict", "1", 0);
|
||||
cl_maxfps = Cvar_Get("cl_maxfps", "30", CVAR_ARCHIVE);
|
||||
cl_maxfps = Cvar_Get("cl_maxfps", "60", CVAR_ARCHIVE);
|
||||
cl_drawfps = Cvar_Get("cl_drawfps", "0", CVAR_ARCHIVE);
|
||||
cl_async = Cvar_Get("cl_async", "0", CVAR_ARCHIVE);
|
||||
|
||||
|
|
Loading…
Reference in a new issue