Quoting the man page of vsnprintf:
RETURN VALUE
Upon successful return, these functions return the number of characters printed
(excluding the null byte used to end output to strings).
The functions snprintf() and vsnprintf() do not write more than size bytes (including
the terminating null byte ('\0')). If the output was truncated due to this limit,
then the return value is the number of characters (excluding the terminating null
byte) which would have been written to the final string if enough space had been
available. Thus, a return value of size or more means that the output was truncated.
(See also below under NOTES.)
If an output error is encountered, a negative value is returned.
[...]
The glibc implementation of the functions snprintf() and vsnprintf() conforms to the
C99 standard, that is, behaves as described above, since glibc version 2.1. Until
glibc 2.0.6, they would return -1 when the output was truncated.
Replace `mem_free` by `free`, and `mem_alloc` by `malloc` or `calloc`
(the latter one being used to allocate a zeroed array of elements,
sometimes, this makes a call to `mem_zero` superfluous).
This results in having to remove `mem_stats` which previously recorded
the number of allocations and their size that the Teeworlds code did
directly.
Remove OOM handling in `src/game/client/components/binds.cpp`.
Remove needless copying in the CSV code in
`src/game/client/components/statboard.cpp`.
`str_utf8_isspace` now returns true if the passed code point renders as
a space, instead of when not.
Add `str_utf8_trim_right`, use this function and
`str_utf8_skip_whitespaces` in the server.
Add tests for the three functions
1055: Keep track of lost frames and update time r=heinrich5991 a=Jupeyy
The problem a friend was occuring was, that on a fresh Windows install settings like cl_refresh_rate are set to 480.
Since the render calls take longer time than no render calls, it happened that client was sleeping on one update cycle and then took to long in another, where it called the render functions, leeding to less FPS than the cl_refresh_rate. this caused mouse lags and rarely frame drops.
another thing is, that select on Windows is non microsecond accurate, or just often returns too early, which caused that the refresh rate is much too high, or even ignored, (probably windows can only sleep on milliseconds, or again, is extremly inaccurate).
Another things on windows is that time_freq might be a "very odd" number ^^
i mean like on unix it's one microsecond (1,000,000 = 1s), but on windows the time_freq depends on the CPU leading to inaccurate calculation of the sleep time and render time.
This wasn't insanly huge issue, but probably skipped a few microseconds here and there.
This fix should stabilize the frames. I'd like to hear your opinion on this tho.
