com_maxfps caps fps higher than specified

[joebonrichie]

Describe the bug
com_maxfps caps the fps at a higher rate than specified according to fps 1

To Reproduce
Steps to reproduce the behavior:

1. Set fps 1 obverse the fps is 90 during gameplay whilst the default value of com_maxfps is 85
2. Change com_maxfps to 144, obverse the fps is 166

Expected behavior
FPS to not exceed the value of com_maxfps

Screenshots (OPTIONAL)
If applicable, add screenshots to help explain your problem.

Logs
N/A

Version information (please complete the following information):

• OS: Solus
• OS Version Rolling
• OpenMoHAA Version: 48c2d02

Dump (OPTIONAL)
N/A

Additional context (OPTIONAL)
N/A

[smallmodel]

It's an issue that should be addressed upstream: https://github.com/ioquake/ioq3/blob/cc18246f22ab033e1b17af4616a68e9ea2e873db/code/qcommon/common.c#L3119 it's in milliseconds, divide 1000 by 143 or 166, it will always be 6 milliseconds (the higher the value, the less precise it will be). The solution could be to use nanoseconds rather than milliseconds.
To cap to the monitor refresh rate, r_swapInterval 1 can be used instead

[mohaa-man]

This same "issue" exists with the original game engine, for the aforementioned reason. IOQuake/OpenMOHAA does have an alternative frame timer you can enable if your system timer's resolution within the select() call is too low:

com_busyWait 1

See:
https://ioquake3.org/help/players-guide/

I have found that the swap interval (aforementioned) also actually works (it does not in the original game, at least not in WINE on Linux). I did have to "force" the nVidia driver to sync to the correct display with an env var.