search

ioquake / ioq3

The ioquake3 community effort to continue supporting/developing id's Quake III Arena
https://ioquake3.org/
GNU General Public License v2.0
2.42k stars 529 forks source link

Make emscripten port default to 85 FPS, non-V-sync #675

Open zturtleman opened 5 months ago

zturtleman commented 5 months ago

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() (https://github.com/libsdl-org/SDL/issues/9969 / https://github.com/emscripten-core/emscripten/issues/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 https://github.com/ioquake/ioq3/pull/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).

jdarpinian commented 5 months ago

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.