Multiple CGDMouseMove per frame bug (and other misc bugs)
|Target version:||-||Estimated time:||0.10 hour|
When multiple CGDMouseMove's are received in 1 frame, all previous CGDMouseMove's are discarded.
Bug is most visible on very high (1000HZ) sample rates. Lower framerate also increases the visibility of this bug.
Note: From time to time I explain things poorly, if so, ask, and I will explain it in a different fashion.
Also recommend your read the patch and source code, this will clear up a lot.
Bug 1 (This only affected non-mouse-smoothed players):
In this code _MouseDeltaAX is set to _MouseDeltaAX = x * ClientCfg.FreeLookSpeed;
It should however be _MouseDeltaAX += x * ClientCfg.FreeLookSpeed;
Bug 2 (Affecting all):
if (fabs(_MouseDeltaAX) > epsilon) is used both to set and UNSET _MouseAngleX.
As a result, a subsequent update of a mouse-move of (X=0,Y=1) would reset the fact that X moved.
Bug 3 (Affecting all):
CEventsListener::getMouseAngleY() doesn't reset the delta angle.
This in combination with bugfix-1 would result in an ever-increasing delta.
Possible bug 4:
CUnixEventEmitter::emulateMouseRawMod might be called to often then required.
As a result it's not always sane to flush the XEvents.
I also recommentdropping isMouseAngleY/X and only using getMouseAngleX/Y then detect float == 0 on that. (If this always works.)
(No risk of floating point errors (at least I think), because it will always be reset after reading the to-proccess-angle.)
Suggestion 2: (Topping Suggestion 1)
Move the check "if (fabs(_MouseDeltaAX) > epsilon)" CEventsListener::updateFreeLookPos to EventsListener::isMouseAngleX
This way it's only ran ONCE instead of every time :)
(This also removed the entire suggestion 1 in a cleaner fashion.)
In the current state of affairs, you MUST call getMouseAngleX after isMouseAngleX to keep a sane state.
This should also be fixed for CEventsListener::updateCursorPos ... this suffers from the same bugs, but this isn't too bad. (No bad effects.)
If suggestions and notes are accepted, I will also make a fix for those if you desire.
#1 Updated by Qantourisc over 2 years ago
The mouse is a LOT more sensitive now for me, I need to turn down my sensitivity a LOT.
#2 Updated by Qantourisc over 2 years ago
Still under the impression that there is something wrong, especially when moving along the Y axis...
#3 Updated by Qantourisc over 2 years ago
- A input device capable of producing a lot of sample per second.
- A Linux usbhid device configured with mousepoll option configured lower then 10 (the lower the better).
- OR For windows you'll have to look on the internet to find out how to increase your mouse polling rate.
Alternatively you can hook several mouses to your system to increase the amount of mice events.
#4 Updated by Qantourisc over 2 years ago
Regarding Note #2, it appears it was just low FPS that caused this :)
Turned down FSAA to 4x and now it runs smooth (instead of x16).
#5 Updated by Qantourisc over 2 years ago
- File fixes.diff added
Fixed some bugs in the fix, also addressing bug #1056.
#6 Updated by Qantourisc over 2 years ago
Noticed another bug: there seems to be a significant delay between starting the freelook, and the mouse cursor/freelook being active.
#7 Updated by Qantourisc over 2 years ago
The bug mentioned above is caused by the fact that the freelook now is waaay more sensitive.
Someone forgot to scale it.
(Compared to Windows, Mac, and "Rotate Anti-Lag System")
I can't find it however. (Rather messy stuff :/)
The most likely cause is unix_xent_emitter.cpp:528.
I suspect al has to be devided by the screen-size.
But that's impossible, as CGDMouse is not a float ... unless this is a design flaw.
Need input, otherwise the next time I'll work on this is next weekend.