Hallo,

There's a bug in ezquake which makes it more difficult to look left than to look right. It affects every platform and can be tested by:

fov 5
sensitivity 0.01
slooooowly move the mouse left; it'll either not move at all, or move a tiny bit and get "stuck" to where it won't move anymore

The offending code is in cl_input.c in the CL_AdjustAngles() function:

if (!(in_strafe.state & 1))
{
speed = basespeed * cl_yawspeed.value;
if ((cl.fpd & FPD_LIMIT_YAW) || allow_scripts.value < 2)
speed = bound(-900, speed, 900);
speed *= frametime;
cl.viewangles[YAW] -= speed * CL_KeyState(&in_right, true);
cl.viewangles[YAW] += speed * CL_KeyState(&in_left, true);
cl.viewangles[YAW] = anglemod(cl.viewangles[YAW]);
}

This whole block of code looks to be a large typo of some kind...

Anyway, this affects even high sensitivity users to some extent. Nobody will probably ever notice (since nobody but me ever has noticed so far? :p) but, still, it is /harder to look left than it is to look right/ :p

OMG this is TRUE!!!
in my ezQuake here the bug looks different though...
(maybe couse i'm using IN_MOUSE 3)
---> It moves perfect to the left, but LESS then it moves to the right....
(it's moving MORE to RIGHT then to LEFT)

It is nice that you found such a bug.

However I do not see anything wrong in the code above.
It is mostly about pressing left and right keys on keyboard.

It is some chance that in anglemod it is conversion from float to int via (int)x or something like it.
In general it is a mistake to make such a conversion.
It should be done in following way: x >= 0 ? (int)(x+0.5) : (int)(x-0.5)

If there are no any conversion from float to int in anglemod, than I believe the error is not related to quoted code at all.
Hard to say more without looking to source code.

Actually it's not a bug in that sense. The anglemod implementation is rounding to 16bit precision (for no reason apparantly in this case), that's why it behaves like it does when doing extremely small movements. "Normal gameplay" isn't affected, but after speaking with Spike it seems there's no reason at all to limit the precision to 16bit in this case.

b1aze: It's not a float to int conversion problem, however thats a usable symmetrical round from floating point to integer if your numbers ain't going to high.

Nice catch

Too bad it's ezQuake, if it was a Skype's bug maybe you would get a XBOX as a prize!
=D