This was so broken... Casting the type of an array to silence a
warning... It worked on x86, of course. But gave a SIGBUS on ARM.
Do it right, cast / copy the content of the array into another
array of the correct type. Yeah.
This fixes issue #231.
This step height is used by several evelators, leading to stuttering due
to misspredictions. Additionally half height steps weren't smoothed by
the synchronous client.
Predicting these steps leads to a heavily stuttering elevator in
hangar1. I think that steps between 94 and 98 can't appear on stairs, so
just remove them. If I'm wrong we need a hack to the hack ontop of the
hack... ^^
While the bugfix in a6f4a3b made the steping prediction working for
stairs, elevators are still stuttering. r1q2s code solves this problem
and is a little bit faster. Use it instead.
We're missusing the current frame to pass data from the input subsystem
to the movement prediction without a server frame. While we can use the
current frame for the movements itself, it's not finished and thus
unsuitable for stair step prediction. Also oldframe is determined
wrongly. As a result the player "jumps" over stairs.
This is largely based upon the cl_async 1 mode from KMQuake2, which in
turn is based upon r1q2. The origins of this code may be even older...
Different to KMQuake2 the asynchonous mode is not optional, the client
is always asynchonous. Since we're mainly integrating this rather
fundamental change to simplify the complex internal timing between
client, server and refresh, there's no point in keeping it optional.
The old cl_maxfps cvar controls the network frames. 30 frames should be
enough, even Q3A hasn't more. The new gl_maxfps cvar controls the render
frames. It's set to 95 fps by default to avoid possible remnant of the
famous 125hz bug.
