frederik
/
xserver
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

dix: document DoGetDirection's maths 

This is the best explanation I can come up with, but it seems to hold true
for my example values.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
This commit is contained in:
Peter Hutterer 2011-04-20 11:49:57 +10:00
parent 7513190ec7
commit df90db892d
1 changed files with 10 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
dix/ptrveloc.c
View File

@ -483,8 +483,16 @@ DoGetDirection(int dx, int dy){
#else #else
r = atan2(dy, dx); r = atan2(dy, dx);
#endif #endif
/* find direction. We avoid r to become negative, /* find direction.
* since C has no well-defined modulo for such cases. */ *
* Add 360° to avoid r become negative since C has no well-defined
* modulo for such cases. Then divide by 45° to get the octant number,
* e.g. 0 <= r <= 1 is [0-45]°
* 1 <= r <= 2 is [45-90]°
* etc.
* But we add extra 90° to match up with our N, S, etc. defines up
* there, rest stays the same.
*/
r = (r+(M_PI*2.5))/(M_PI/4); r = (r+(M_PI*2.5))/(M_PI/4);
/* this intends to flag 2 directions (45 degrees each), /* this intends to flag 2 directions (45 degrees each),
* except on very well-aligned mickeys. */ * except on very well-aligned mickeys. */