Mouse look

[Dawoodoz]

To be able to rotate a camera freely with a mouse, the common trick is to hide the mouse and move it to the center of the screen very often while recording relative cursor motion. The problems with this old trick is that the cursor might stay hidden when the program crashes, and that the camera will spin very fast from rejecting the new cursor position when entering absolute cursor positions using stylus, touch-screen or eye-tracking.

While the framework should try to avoid contemporary hacks as much as possible in order to work with many different input techniques that computers may have in the future, there are ways to limit the damage. One can use an empty image as a cursor icon and associate it with the window, so that moving the mouse outside during a crash will make the cursor visible even if the program is not responding. Games can have multiple input modes for camera rotation and reset the cursor position in randomized bursts to detect when the input device uses absolute cursor positions. If the platform does not support hiding and moving the cursor, one should safely fall back on the absolute position mode that does not require moving the cursor.

For stylus without screen When using absolute positioning to control a camera, one can limit lattitude to the screen's height, let the crosshair move sideways within a dead zone, and start spinning the camera faster the furter out the cursor goes to left or right sides.

For touch-screen, stylus with screen or eye tracking If the input is mapped directly to the screen, it may make sense to not move the camera's lattitude and instead move the crosshair freely over the dead zone, while still rotating when hovering over left and right edges.

Another problem is how to synchronize between mouse move events arriving before and after setting the pointer location when reading mouse movements, because there will be delays from both X11 messages and buffering of events. For small motions, one can select new origins at distinct locations perpendicular to the direction of motion, making it physically difficult to create a move jumping into another region in a single frame.

[Dawoodoz]

Games that don't even use a mouse as input could benefit from just hiding the cursor as a start. This could be implemented in different ways on different systems by keeping the interface simple.

[Dawoodoz]

An invisible cursor has now been implemented for the X11 window backend.

[Dawoodoz]

Implemented cursor hiding for MS-Windows.

[Dawoodoz]

Still haven't found a reliable way to mark fake mouse move events to ignore their offset when accumulating.

• Using XWarpPointer in X11 did not give any hint of the artificial XMotion event not being sent by the user.

• Skipping the next mouse move event does not consider network delays, causing both false positives and false negatives.

• Using positions to filter away events using acceleration can have false positives when moving with high acceleration.

• Using X11 extensions would risk not working at all on some computers.

• Doing multiple calls to XWarpPointer using different locations confirmed to be within window bounds, first in the opposite side of the current velocity and then back at the center, could at least be reasonably difficult to break with a physical mouse.

[Dawoodoz]

A plain wrapper over the system calls for setting the cursor position is now in the experimental branch, but even the wrapper felt like a hack due to the strange limitations on X11's XWarpPointer, which did not allow catching the cursor outside of the client area. As long as one is aware of the differences between systems, such as client area limitations and system delays, it should be possible to implement mouse-look navigation.