|
Allegro 4.1.17 - Mouse Acceleration |
Richard Phipps
Member #1,632
November 2001
|
Well, I tried the new mouse code in Allegro 4.1.17 with Sunny Ball. It's better than the old code, but I think it's still too fast. Attached is a modified 4.1.16 version that James Lohr kindly sent me. The mouse movement is slower, but feels much smoother to me. I'd rather use this, but will then of course lose the 4.1.17 advantages. Is there any chance that new versions of Allegro will have an acceleration setting so we can set it to suit? Or even get the raw mouse mickeys to scale in our own way? |
gnolam
Member #2,030
March 2002
|
What's wrong with the current set_mouse_speed() and mouse mickeys? -- |
Chris Katko
Member #1,881
January 2002
|
Quote: Is there any chance that new versions of Allegro will have an acceleration setting so we can set it to suit? How hard is it to just track the movements and accelerate them yourself? Also, isn't mouse acceleration OS provided? -----sig: |
Richard Phipps
Member #1,632
November 2001
|
See this thread: [url http://www.allegro.cc/forums/view_thread.php?_id=419528] AFAIK we could see the scaling method was also the problem. Although this has been changed in 4.1.17 I'm not sure if you can get the raw data for the mouse mickeys. You may be able to now.. |
Evert
Member #794
November 2000
|
Quote: Attached is a modified 4.1.16 version that James Lohr kindly sent me. The mouse movement is slower, but feels much smoother to me. That's strange, since his original patch made it more or less unmodified into 4.1.17 (where there are still some problems with it that have been fixed in CVS) Quote: I'd rather use this, but will then of course lose the 4.1.17 advantages. Not to mention those of all future versions. By the way, may I say that you've picked a horrible time to upgrade to 4.1.17? Quote: Is there any chance that new versions of Allegro will have an acceleration setting so we can set it to suit? I've never used set_mouse_speed() personally, but I suppose you could use that. Quote: Or even get the raw mouse mickeys to scale in our own way? No plans. The main issue with mickeys being that reporting them reliably in a portable way is rather tricky (read: impossible). Again, the lack of active developers using Windows doesn't help much either... |
Richard Phipps
Member #1,632
November 2001
|
Quote: By the way, may I say that you've picked a horrible time to upgrade to 4.1.17? Oh noes, a 4.1.18 release? Couldn't we set the set_mouse_speed to 0 to get the raw data though? |
james_lohr
Member #1,947
February 2002
|
Quote: What's wrong with the current set_mouse_speed() and mouse mickeys? The problem is that the mickeys are accelerated and accelerated incorrectly. Quote: That's strange, since his original patch made it more or less unmodified into 4.1.17 (where there are still some problems with it that have been fixed in CVS) Well actually I had a look at wmouse.c in 4.1.17 . It looks like my patch has been tampered with in a way as to completely remove the improvement that I made. Why on earth has: static int last_was_x = 0; . . . if (last_was_x) last_mickeyy = 0; been added? It undoes exactly what my patch added. Furthermore I seem to recall that my patch was not applied at all to 4.1.16 (but i don't have a 4.1.16 handy to check this). At the moment I'm having to rewrite some of wmouse.c every time I get a new version of the WIP 'cause the mouse acceleration has gone back to being absolutely awful.
|
Richard Phipps
Member #1,632
November 2001
|
I agree with James, his patched 4.1.16 feels much nicer than the feeling from 4.1.17 |
Evert
Member #794
November 2000
|
Quote: Why on earth has: static int last_was_x = 0; been added?
As I recall, because messages being send to the message handler aren't guarenteed to be alternating x/y pairs. I'm not sure what the differences were, but it should be functionally similar. Also, check out current CVS for some more changes that were made. I don't recall off the top of my head what they were, but the sourceforge tracker should help there. Quote: Furthermore I seem to recall that my patch was not applied at all to 4.1.16 Wether for 4.1.16 or 4.1.17, I did apply something equivalent to the patch you posted at some point (manually, the patch didn't apply through the patch program for some reason). Quote: At the moment I'm having to rewrite some of wmouse.c every time I get a new version of the WIP 'cause the mouse acceleration has gone back to being absolutely awful. Rather than hacking about your copy of Allegro, it'd be really nice if you bring things like these up after a WIP is released - either on the forums, or through private message or e-mail. Because things that are broken don't get fixed in the next release unless we know they're broken. EDIT: 1===================================================================
2RCS file: /cvsroot/alleg/allegro/src/win/wmouse.c,v
3retrieving revision 1.37
4retrieving revision 1.38
5diff -u -r1.37 -r1.38
6--- alleg/allegro/src/win/wmouse.c 2004/10/20 20:03:31 1.37
7+++ alleg/allegro/src/win/wmouse.c 2004/12/01 23:03:57 1.38
8@@ -92,8 +92,8 @@
9 #define MAF_DEFAULT 1 /* mouse acceleration parameters */
10 static int mouse_accel_fact = MAF_DEFAULT;
11 static int mouse_accel_mult = MAF_DEFAULT;
12-static int mouse_accel_thr1 = 5;
13-static int mouse_accel_thr2 = 16;
14+static int mouse_accel_thr1 = 50; /* 50 = 5^2 *2 */
15+static int mouse_accel_thr2 = 512; /* 512 = 16^2 *2 */
16
17 static int mouse_minx = 0; /* mouse range */
18 static int mouse_miny = 0;
19@@ -208,31 +208,39 @@
20 */
21 static void mouse_dinput_handle_event(int ofs, int data)
22 {
23+ static int last_mickeyx = 0;
24+ static int last_mickeyy = 0;
25+ int mag;
26+
27 switch (ofs) {
28
29 case DIMOFS_X:
30 if (!gfx_driver || !gfx_driver->windowed) {
31 if (mouse_accel_mult) {
32- if (ABS(data) >= mouse_accel_thr2)
33+ mag = last_mickeyx*last_mickeyx + last_mickeyy*last_mickeyy;
34+ if (mag >= mouse_accel_thr2)
35 data *= (mouse_accel_mult<<1);
36- else if (ABS(data) >= mouse_accel_thr1)
37+ else if (mag >= mouse_accel_thr1)
38 data *= mouse_accel_mult;
39 }
40
41 dinput_x += data;
42+ last_mickeyx = data;
43 }
44 break;
45
46 case DIMOFS_Y:
47 if (!gfx_driver || !gfx_driver->windowed) {
48 if (mouse_accel_mult) {
49- if (ABS(data) >= mouse_accel_thr2)
50+ mag = last_mickeyx*last_mickeyx + last_mickeyy*last_mickeyy;
51+ if (mag >= mouse_accel_thr2)
52 data *= (mouse_accel_mult<<1);
53- else if (ABS(data) >= mouse_accel_thr1)
54+ else if (mag >= mouse_accel_thr1)
55 data *= mouse_accel_mult;
56 }
57
58 dinput_y += data;
59+ last_mickeyy = data;
60 }
61 break;
(Or check the coloured diff [url http://cvs.sourceforge.net/viewcvs.py/alleg/allegro/src/win/wmouse.c?r1=1.37&r2=1.38]here[/url]) 1===================================================================
2RCS file: /cvsroot/alleg/allegro/src/win/wmouse.c,v
3retrieving revision 1.39
4retrieving revision 1.40
5diff -u -r1.39 -r1.40
6--- alleg/allegro/src/win/wmouse.c 2004/12/04 13:24:17 1.39
7+++ alleg/allegro/src/win/wmouse.c 2004/12/05 08:56:32 1.40
8@@ -93,8 +93,8 @@
9 #define MAF_DEFAULT 1 /* mouse acceleration parameters */
10 static int mouse_accel_fact = MAF_DEFAULT;
11 static int mouse_accel_mult = MAF_DEFAULT;
12-static int mouse_accel_thr1 = 50; /* 50 = 5^2 *2 */
13-static int mouse_accel_thr2 = 512; /* 512 = 16^2 *2 */
14+static int mouse_accel_thr1 = 5 * 5;
15+static int mouse_accel_thr2 = 16 * 16;
16
17 static int mouse_minx = 0; /* mouse range */
18 static int mouse_miny = 0;
19@@ -211,12 +211,15 @@
20 {
21 static int last_mickeyx = 0;
22 static int last_mickeyy = 0;
23+ static int last_was_x = 0;
24 int mag;
25-
26+
27 switch (ofs) {
28
29 case DIMOFS_X:
30 if (!gfx_driver || !gfx_driver->windowed) {
31+ if (last_was_x)
32+ last_mickeyy = 0;
33 if (mouse_accel_mult) {
34 mag = last_mickeyx*last_mickeyx + last_mickeyy*last_mickeyy;
35 if (mag >= mouse_accel_thr2)
36@@ -227,11 +230,14 @@
37
38 dinput_x += data;
39 last_mickeyx = data;
40+ last_was_x = 1;
41 }
42 break;
43
44 case DIMOFS_Y:
45 if (!gfx_driver || !gfx_driver->windowed) {
46+ if (!last_was_x)
47+ last_mickeyx = 0;
48 if (mouse_accel_mult) {
49 mag = last_mickeyx*last_mickeyx + last_mickeyy*last_mickeyy;
50 if (mag >= mouse_accel_thr2)
51@@ -242,6 +248,7 @@
52
53 dinput_y += data;
54 last_mickeyy = data;
55+ last_was_x = 0;
56 }
57 break;
(or [url http://cvs.sourceforge.net/viewcvs.py/alleg/allegro/src/win/wmouse.c?r1=1.39&r2=1.40]colour diff[/url]) 1===================================================================
2RCS file: /cvsroot/alleg/allegro/src/win/wmouse.c,v
3retrieving revision 1.40
4retrieving revision 1.41
5diff -u -r1.40 -r1.41
6--- alleg/allegro/src/win/wmouse.c 2004/12/05 08:56:32 1.40
7+++ alleg/allegro/src/win/wmouse.c 2004/12/07 17:37:30 1.41
8@@ -209,8 +209,8 @@
9 */
10 static void mouse_dinput_handle_event(int ofs, int data)
11 {
12- static int last_mickeyx = 0;
13- static int last_mickeyy = 0;
14+ static int last_data_x = 0;
15+ static int last_data_y = 0;
16 static int last_was_x = 0;
17 int mag;
18
19@@ -219,9 +219,11 @@
20 case DIMOFS_X:
21 if (!gfx_driver || !gfx_driver->windowed) {
22 if (last_was_x)
23- last_mickeyy = 0;
24+ last_data_y = 0;
25+ last_data_x = data;
26+ last_was_x = 1;
27 if (mouse_accel_mult) {
28- mag = last_mickeyx*last_mickeyx + last_mickeyy*last_mickeyy;
29+ mag = last_data_x*last_data_x + last_data_y*last_data_y;
30 if (mag >= mouse_accel_thr2)
31 data *= (mouse_accel_mult<<1);
32 else if (mag >= mouse_accel_thr1)
33@@ -229,17 +231,17 @@
34 }
35
36 dinput_x += data;
37- last_mickeyx = data;
38- last_was_x = 1;
39 }
40 break;
41
42 case DIMOFS_Y:
43 if (!gfx_driver || !gfx_driver->windowed) {
44 if (!last_was_x)
45- last_mickeyx = 0;
46+ last_data_x = 0;
47+ last_data_y = data;
48+ last_was_x = 0;
49 if (mouse_accel_mult) {
50- mag = last_mickeyx*last_mickeyx + last_mickeyy*last_mickeyy;
51+ mag = last_data_x*last_data_x + last_data_y*last_data_y;
52 if (mag >= mouse_accel_thr2)
53 data *= (mouse_accel_mult<<1);
54 else if (mag >= mouse_accel_thr1)
55@@ -247,8 +249,6 @@
56 }
57
58 dinput_y += data;
59- last_mickeyy = data;
60- last_was_x = 0;
61 }
62 break;
([url http://cvs.sourceforge.net/viewcvs.py/alleg/allegro/src/win/wmouse.c?r1=1.40&r2=1.41]colour diff[/url]). |
Richard Phipps
Member #1,632
November 2001
|
I'm now confused. But I don't understand why James's 1.38 patch seems to be much less acclerated.. |
james_lohr
Member #1,947
February 2002
|
Oh sorry, I just remembered what's going on . 1.40, 1.41 look fine, the reason why the one I sent Richard was more smooth was because I wrote two patches - a simple one (the one implemented and improved on above) and a second one which is a bit more complicated. The second one is the one I use myself and is the one I sent Richard. What a mess .
|
Richard Phipps
Member #1,632
November 2001
|
Can we have the nice but complicated one then? |
james_lohr
Member #1,947
February 2002
|
Sure, I'll write another patch this time for the wmouse.c in 4.1.17 with "added smoothness". I'll also include the changes made during CVS to my original patch (assuming they do not have a negative affect).
|
Evert
Member #794
November 2000
|
Best to make a diff against current CVS rather than 4.1.17 though... |
Richard Phipps
Member #1,632
November 2001
|
Great, thanks James! Although if 4.1.18 is going to be released in the next few days it might be best to wait.. |
Evert
Member #794
November 2000
|
That's why I'd like a patch against current CVS rather than 4.1.17: so that I can possibly squeeze it into 4.1.18. I guess it's getting a bit late for this though (the release is already overdue and I don't want to postpone it too much longer), so I guess it'll have to be the release after that... |
Richard Phipps
Member #1,632
November 2001
|
If you release 4.1.19 in a few months time I can wait.. |
Evert
Member #794
November 2000
|
Originally, the plan was to go from 4.1.17 to 4.2.0 RC1. However, there are so many new goodies that we really need to put out an extra WIP to give people time to test them all and make sure things are really stable enough. So unless something goes wrong, 4.1.19 in a few months is something that's not really supposed to happen. The reason to get 4.2 out soon is because while development is proceeding on 4.2, it's holding back 4.3. Also, it's about time there was a stable release that supports MacOSX. |
Richard Phipps
Member #1,632
November 2001
|
Elias
Member #358
May 2000
|
Sorry, I didn't read all of this thread, but did someone see this: http://www.allegro.cc/forums/view_thread.php?_id=437084 It seems to me that 4.1.18 (current CVS) already fixes the acceleration problems of 4.1.16 and 4.1.17. -- |
Mike Farrell
Member #248
April 2000
|
I know this is off topic but, is there any way to turn mouse acceleration off so it just acts normal? I notice it's fine unless I run my allegro apps in windows and fullscreen. |
Elias
Member #358
May 2000
|
I think, the problems in windows/fullscreen are just in 4.1.16 and 4.1.17 - mouse accel is simply broken in that case. (In windowed mode, it always just uses the windows cursor position, AFAIK). But maybe there should be a function set_mouse_accel, since there also is a set_mouse_speed.. -- |
Mike Farrell
Member #248
April 2000
|
This app is using allegro 4.0.3 |
Elias
Member #358
May 2000
|
Well, you could try if disabling the acceleration code brings any improvement. Open src/win/wmouse.c, and look for mouse_accel_thr1 and mouse_accel_thr2, set them both to something like 1000000. That should disable it. Then recompile. If there's really an improvement, we could provide a function or config variable to disable it. -- |
|