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:
Yamagi Burmeister 2016-08-12 07:38:10 +02:00
parent 070d94ec77
commit d6136cbba5

View file

@ -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);