Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Video of the OS X mouse problem

This thread is locked; no one can reply to it. rss feed Print
Video of the OS X mouse problem
Thomas Harte
Member #33
April 2000
avatar

I have posted about this before, but am not entirely sure that I communicated the problems that affect mouse using programs under OS X, which are that the Allegro cursor is often at a different position to the OS X mouse cursor. I haven't been able to follow the Allegro code very well, but it appears that once it is detected the cursor is over the application window, the mouse mickeys are captured and used to move the Allegro mouse cursor. This disregards the low frame rate of Allegro programs under OS X in that the real mouse cursor may move quite a distance into the Allegro window before Allegro realises where it is, and as a result the Allegro mouse cursor will duplicate its movements from a different position.

To demonstrate this, I used the following code:

1#include "allegro.h"
2 
3int main(int argc, const char *argv[])
4{
5 BITMAP *back;
6 
7 allegro_init();
8 install_mouse();
9
10 if (set_gfx_mode(GFX_AUTODETECT_WINDOWED, 800, 600, 0, 0)) {
11 allegro_message("Error setting 800x600x8 gfx mode:\n%s\n", allegro_error);
12 return -1;
13 }
14 
15 back = create_bitmap(SCREEN_W, SCREEN_H);
16 clear(back);
17 show_mouse(back);
18 while(!mouse_b)
19 {
20 blit(back, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H);
21 }
22 
23 destroy_bitmap(back);
24 return 0;
25}
26END_OF_MAIN();

I've attached a video showing the bug in action. The "real" mouse cursor is the one to the right, the Allegro cursor is the one to the left. This is demonstrated when the real cursor is able to compress the distance between the two by pushing the Allegro cursor against the edge of the window.

I hope this makes the problem clear. Apologies that the movie is a mov and not an avi or mpeg, I used iMovie to trim the clip down and being not very proficient with that I didn't try to pursue the "author DVD" type output to see if I could produce something more portable.

Evert
Member #794
November 2000
avatar

Quote:

but am not entirely sure that I communicated the problems that affect mouse using programs under OS X, which are that the Allegro cursor is often at a different position to the OS X mouse cursor.

Now that you mention it again, I do remember that you brought this up before.

Quote:

I haven't been able to follow the Allegro code very well, but it appears that once it is detected the cursor is over the application window, the mouse mickeys are captured and used to move the Allegro mouse cursor.

Would it be possible to use the mouse position returned by the operating system directly and derive mickeys from that, rather than calculating the position from mickeys? Would that solve (or at least soften) the problem?

Quote:

I've attached a video showing the bug in action. The "real" mouse cursor is the one to the right, the Allegro cursor is the one to the left.

Is it normal that the OS cursor remains visible (it shouldn't)? Or do I misunderstand the video?

Quote:

Apologies that the movie is a mov and not an avi or mpeg

Hm? Mplayer shows all of those just fine.

About your code... it's rarely a good idea in practice to use show_mouse() on a memory surface, but it should still not do what it does in that movie. Does the problem become less severe if you do show_mouse(screen)?
Actually, in practice you'd probably want the OS to draw the mouse cursor for you, which you can accomplish by calling enable_hardware_cursor() before show_mouse(screen). Does that circumvent the problem?

Thomas Harte
Member #33
April 2000
avatar

Quote:

Would it be possible to use the mouse position returned by the operating system directly and derive mickeys from that, rather than calculating the position from mickeys? Would that solve (or at least soften) the problem?

I do not know for certain. I certainly believe that it would, but as I do not have the code skills (both Allegro and OS X) to test it, I wouldn't like to say for certain.

Quote:

Is it normal that the OS cursor remains visible (it shouldn't)? Or do I misunderstand the video?

I've always been a bit confused about this. The OS cursor seems to remain visible in any Allegro program that calls install_mouse, otherwise it is invisible.

Quote:

Hm? Mplayer shows all of those just fine.

That's good. I just know that mov is hardly as pervasive a file format as the other two. Even given that avi is a container and not a video format.

Quote:

About your code... it's rarely a good idea in practice to use show_mouse() on a memory surface, but it should still not do what it does in that movie. Does the problem become less severe if you do show_mouse(screen)?

The problem appears to be directly related to frame rate. The demo program is set up as it is just because using an actual blit gives a sufficiently realistic frame rate to demonstrate the problem and show_mouse that way around makes for a shorter example. And, as we all know, the shortest possible example should be posted!

Quote:

Actually, in practice you'd probably want the OS to draw the mouse cursor for you, which you can accomplish by calling enable_hardware_cursor() before show_mouse(screen). Does that circumvent the problem?

Then the positions reported to Allegro programs are as per the positioning of the software cursor. As it does not always correlate to the position of the real cursor this makes for a non-sensical experience where no mouse click acts quite where it seems...

If you move the cursor very slowly into the Allegro window then Allegro will usually latch the software mouse position to it more or less correctly.

Peter Hull
Member #1,136
March 2001

I don't remember Thomas mentioning it but I remember Ultio mentioning it.
It's on the todo list, I asked Ultio if it had been fixed and he said it had as far as he could tell.

Thomas, does it always do this (or can you reproducibly force it) or is it random?
Thanks,

Pete

[edit removed a question you'd already answered :P ]

Evert
Member #794
November 2000
avatar

Quote:

I certainly believe that it would, but as I do not have the code skills (both Allegro and OS X) to test it, I wouldn't like to say for certain.

Pete? ;)

Quote:

I've always been a bit confused about this. The OS cursor seems to remain visible in any Allegro program that calls install_mouse, otherwise it is invisible.

That's a bug then. What puzzles me is that I haven't heard that many bugreports on this.

Quote:

Then the positions reported to Allegro programs are as per the positioning of the software cursor. As it does not always correlate to the position of the real cursor this makes for a non-sensical experience where no mouse click acts quite where it seems...

Hmm... so this is due to there being a difference in the location where the cursor is drawn (by the OS) and where Allegro thinks the cursor really is? The solution should be similar: have Allegro get the cursor position directly from the OS rather than from mickeys.

Thomas Harte
Member #33
April 2000
avatar

Quote:

Thomas, does it always do this (or can you reproducibly force it) or is it random?

It happens most of the time if I cross the mouse cursor into the window quickly. It doesn't always happen, but it not happening is rare. This is the latest Allegro (4.2.0 RC2) so whatever Ultio may have done to CVS will not be apparent to me.

Matthew Leverton
Supreme Loser
January 1999
avatar

I didn't watch the movie, but I have the same problem. If I open the grabber in windowed mode and move the mouse immediately, the mouse cursor is off by the amount I moved the mouse. OS X 10.4.

Fiddler
Member #5,385
January 2005

I tried to run this code on Windows, just to see if the bug is there. It is not, however the code crashes on the destruction of the memory bitmap. I remember the discussion about disallowing (or discouraging) show_mouse() with memory bitmaps, but I cannot remember if this was before the RC2 or after. The RC2 docs don't mention anything, so I assume it was after - has this issue been rectified?

The Open Toolkit: a game development library for .Net/Mono.
http://www.opentk.com

Evert
Member #794
November 2000
avatar

Quote:

I tried to run this code on Windows, just to see if the bug is there. It is not,

That's to be expected, it's a bug with Allegro's mouse driver. The Windows mouse driver is completely different from the OS X code, or the X11 code for that matter.
Still good to double check. :)

Quote:

however the code crashes on the destruction of the memory bitmap. I remember the discussion about disallowing (or discouraging) show_mouse() with memory bitmaps, but I cannot remember if this was before the RC2 or after.

After, I think. In this case, it's to be expected, as there isn't even a
show_mouse(NULL). Still, as a test case to show the problem it isn't a big
deal here.

Peter Hull
Member #1,136
March 2001

sigh

I don't think these things are regressions; I don't think they ever worked quite right. I don't get 2 cursors on the grabber but I can make the pointer point to the wrong thing by wriggling the mouse like a fool while the app is starting. I do get 2 cursors for Thomas's program though.

I'll look into it

Pete

[edit]
It's easy enough to get the absolute mouse position - the slight snag is that it's in screen coordinates relative to the bottom-left. Have a play with the attached program:

1#import <allegro.h>
2#import <AppKit/Appkit.h>
3 
4int main(void) {
5 NSPoint pt;
6 NSRect rc;
7 BITMAP* s;
8 int mx, my, ox, oy;
9 int c_os, c_al, c_bl, c_di;
10 allegro_init();
11 install_mouse();
12 set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0,0);
13 s=create_bitmap(SCREEN_W, SCREEN_H);
14 show_mouse(screen);
15 c_os=makecol(0,255,255);
16 c_al=makecol(255,255,255);
17 c_bl=makecol(0,0,0);
18 c_di=makecol(255,128,255);
19 while (!mouse_b) {
20 pt=[NSEvent mouseLocation];
21 rc=[NSWindow contentRectForFrameRect:[[NSApp mainWindow] frame] styleMask: [[NSApp mainWindow] styleMask]];
22 ox=(int) (pt.x-rc.origin.x);
23 oy=(int) -(pt.y-rc.origin.y-rc.size.height);
24 mx=mouse_x;
25 my=mouse_y;
26 clear_bitmap(s);
27 textprintf_ex(s, font, 0, 0, c_al, c_bl, "Allegro: %d, %d ", mx, my);
28 textprintf_ex(s, font, 0, 20, c_os, c_bl, "OS : %d, %d ", ox, oy);
29 textprintf_ex(s, font, 0, 40, c_di, c_bl, "Diff : %d, %d ", ox-mx, oy-my);
30 circle(s, mx, my, 5, c_al);
31 circle(s, ox, oy, 5, c_os);
32 blit(s, screen, 0, 0, 0, 0, s->w, s->h);
33 }
34 return 0;
35} END_OF_MAIN()

The problem arises as the mouse crosses the window border, for me it happens quite rarely (look at the purple numbers)

Thomas Harte
Member #33
April 2000
avatar

Quote:

The problem arises as the mouse crosses the window border, for me it happens quite rarely (look at the purple numbers)

For me it happens very often, but I expect my machine, a 667Mhz G4, is slower than yours. I found that the purple numbers settled on one value then while I moved the mouse around they went all over the place, finally settling back on their original values when I let the mouse rest.

I found that the cyan circle always appeared to be following the mouse as well as can be expected given Allegro's OS X frame rates.

Quote:

t's easy enough to get the absolute mouse position - the slight snag is that it's in screen coordinates relative to the bottom-left.

I guess that's what happens when you derive your desktop from OpenGL.

Jose Cuervo
Member #5,197
November 2004

It crashed on my machine when I moved my mouse outside the window (multiple times). 10.2.8/800Mhz/Allegro 4.1.6(I know it's old, but its the last version that works)

Evert
Member #794
November 2000
avatar

Quote:

Allegro 4.1.6(I know it's old, but its the last version that works)

That doesn't help at all, precisely because it's so old.
What do you mean by `last version that works'? Allegro 4.2.0 works just fine (well...) on MacOS X.

Peter Hull
Member #1,136
March 2001

Thomas, can you try this patch (attached). It's a hack, just to check I'm on the right track.

The system sends two types of mouse message, one when the mouse moves, the other when it enters the window. The currrent code attempts to set the absolute mouse position from the MouseEnter event, then track it via (delta_x, delta_y) from the MouseMove events. Unfortunately, the deltas are relative to the last MouseMove, not the last MouseEnter. That's one problem. When you move the mouse onto the window, quite often the system sends a MouseEnter and a MouseMove 'together'. The current code ignores any moves sent straight after a enter.

As for the double cursor thing, I think I've sorted that out too but I need to check some more.

Pete

Thomas Harte
Member #33
April 2000
avatar

Quote:

Thomas, can you try this patch (attached). It's a hack, just to check I'm on the right track

Today I truly paid the price for having done a make clean!

I tested using your two circle test and found it worked most of the time, but every so often on window entry the Allegro cursor would jump off so that the purple numbers were -258, 234. Then they would stay that way until I moved the mouse off the window and back onto it. I also found that if the Allegro program was not the foreground window then the white circle would stay where it was when Allegro was last in the foreground, but the cyan circle would still move with the mouse, albeit having assumed a position immediately below the mouse cursor rather than on the cursor's action point.

Jose Cuervo
Member #5,197
November 2004

<QUOTE=Evert>That doesn't help at all, precisely because it's so old.
What do you mean by `last version that works'? Allegro 4.2.0 works just fine (well...) on MacOS X.</QUOTE>
Not on my mac. Don't know why. Tried the Binary, had problems there, tried installing it from source, and half the functions don't work.

Some of my favorite functions dont work on my mac in 4.18 either, so I don't use that.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Some of my favorite functions dont work on my mac in 4.18 either, so I don't use that.

Well, it won't get fixed if you don't speak up and give the devs some usefull information. Not sure if you've noticed, but most of the mac users have few problems. None nearly as sever as the ones you're seeing.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Evert
Member #794
November 2000
avatar

Quote:

tried installing it from source, and half the functions don't work.

You're doing something wrong then, as 4.2 is source compatible with 4.0, just as 4.1.6 is. What doesn't work and what errors do you get?
Note: Deprecation warnings are not errors!

Dominik Pich
Member #6,267
October 2005

Allegro 4.20 compiled fine or me using gcc4 or gcc3.3 on tiger.
I now installed a version compiled with 3.3 for use with the game ufo2000...
all is well BUT for the mouse issue... I reported this bug already for 4.19?!

Im not too good with mac development but is there something I could do to help?
Thanks!

Jose Cuervo
Member #5,197
November 2004

I did some really stupid things with my mac, such as modify some of the internal libraries, and that is the reason 4.18 and above doesn't work. 4.18 worked until I did, so I know what the problem is, I've got to reinstall those libraries, but I don't have the drive to do it.

Plus I'm not doing a lot of development right now, so... It's not on the top of my priority list.

Go to: