SYNOPSIS

#include <vgamouse.h>

void mouse_setwrap(int state);

DESCRIPTION

This routine determines what to do if the mouse position reaches a boundary.

state should be either MOUSE_WRAP, MOUSE_NOWRAP, or a bitwise or of MOUSE_WRAPX, MOUSE_WRAPY, MOUSE_WRAPZ, MOUSE_WRAPRX, MOUSE_WRAPRY, or MOUSE_WRAPRZ. These define if all or the respective coordinates wrap or are clipped at the ends.

This variable has been overloaded for the case of multi-dimensional mice that support rotations and can be used to select the coordinate system used to return the current position of the mouse.

If the above value of state is also ored with MOUSE_ROT_RX_RY_RZ, rotational information will be returned as the angular position as expressed by the total angle wound around the X, Y, and Z axes. This is the simplest coordinate system to use, but it's also the least useful, since angular rotations about perpendicular axes don't commute. There are situations where this system might be useful, for controlling truly independent quantities, such as color, with each axis being used to dial a level of red, green, or blue, but for modeling the actual orientation of a physical object, it's utterly hopeless.

If state is instead ored with MOUSE_ROT_INFINITESIMAL, the angular positions returned are expressed as differences from the previously reported position. If the differences are sufficiently small, the angular displacements will commute with each other and can be used to track the motion of a physical object. Other coordinate systems, such as yaw, pitch, and roll, could be defined, but haven't been done due to lack of time. If you feel you need this feature, send mail to Eric Sharkey <[email protected]> and he just might consider coding it up.

MOUSE_WRAP and MOUSE_ROT_COORDS can be used to mask out the bits used for wrap and coordinate states, respectively.

AUTHOR

This manual page was edited by Michael Weller <[email protected]>. The exact source of the referenced function as well as of the original documentation is unknown.

It is very likely that both are at least to some extent are due to Harm Hanemaayer <[email protected]>.

Occasionally this might be wrong. I hereby asked to be excused by the original author and will happily accept any additions or corrections to this first version of the svgalib manual.