You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the emscripten port starts out using V-sync (requestAnimationFrame) due to a design issue in emscripten that emscripten_set_main_loop_timing() cannot be set before emscripten_set_main_loop() (libsdl-org/SDL#9969 / emscripten-core/emscripten#7100). After running the ioquake3 vid_restart command, V-sync is disabled and it runs at 90 FPS according to cg_drawFPS 1.
Using V-sync may end up being explicitly enabled by #672.
The player movement is tied to the client framerate so I'm not sure if using 60 FPS V-sync by default is a good idea.
If I remember correctly running at 60 FPS has a lower jump height than default com_maxfps 85. (I don't remember specifically where this is relevant.) It's preferable for the client to use com_maxfps 125 for the highest jump height which is known to effect many places (such as the mega health in q3dm13). pmove_fixed 1 avoids player movement being client framerate dependent but it may have other side effects? (This is all kind of player/server specific that ideally the emscripten port should behave the same as other platforms in my opinion.)
It may be possible to use emscripten_set_main_loop_timing() to target com_maxfps instead of sleeping in Com_Frame() to reduce overhead in a web browser while not affecting player movement. This would need to be set after creating the window (as SDL changes it via emscripten's egl implementation), when the com_maxfps cvar changes, and emscripten_set_main_loop(). r_swapInterval could enable using requestAnimationFrame (as already happens through SDL).
The text was updated successfully, but these errors were encountered:
Hmm, using emscripten_set_main_loop_timing(EM_TIMING_SETTIMEOUT, ms) is generally not recommended and likely to introduce stuttering or other issues on the browser side. Also, high frame rate displays are common now. My phone is 120 Hz and my desktop is 240 Hz. I definitely want higher than 85 or 125 FPS by default.
It's unfortunate that player physics are affected by rendering framerate. It seems to me that pmove_fixed is the right solution and any side effects ought to be fixable, though that might be a big job.
Currently the emscripten port starts out using V-sync (requestAnimationFrame) due to a design issue in emscripten that emscripten_set_main_loop_timing() cannot be set before emscripten_set_main_loop() (libsdl-org/SDL#9969 / emscripten-core/emscripten#7100). After running the ioquake3
vid_restart
command, V-sync is disabled and it runs at 90 FPS according tocg_drawFPS 1
.Using V-sync may end up being explicitly enabled by #672.
The player movement is tied to the client framerate so I'm not sure if using 60 FPS V-sync by default is a good idea.
If I remember correctly running at 60 FPS has a lower jump height than default com_maxfps 85. (I don't remember specifically where this is relevant.) It's preferable for the client to use com_maxfps 125 for the highest jump height which is known to effect many places (such as the mega health in q3dm13).
pmove_fixed 1
avoids player movement being client framerate dependent but it may have other side effects? (This is all kind of player/server specific that ideally the emscripten port should behave the same as other platforms in my opinion.)It may be possible to use emscripten_set_main_loop_timing() to target com_maxfps instead of sleeping in Com_Frame() to reduce overhead in a web browser while not affecting player movement. This would need to be set after creating the window (as SDL changes it via emscripten's egl implementation), when the com_maxfps cvar changes, and emscripten_set_main_loop(). r_swapInterval could enable using requestAnimationFrame (as already happens through SDL).
The text was updated successfully, but these errors were encountered: