Mouse Input offset?
sethhope

So after creating a bit of a level editor for an RPG I'm making, I realized that the mouse isn't registering at it's actual position. To test it out, I began drawing a circle at the location of the mouse. I declare 2 integers and set them to event.mouse.x and event.mouse.y at a mouse axes event.

Here's where the weird stuff begins. At the top right of the screen (0,0) the circle follows the mouse perfectly, however, as the mouse progresses towards the bottom right (1024, 800), the circle begins to stray. By the time I get to the bottom right, the circle is about 10 pixels too far right and 10 pixels too far up. I am using Allegro 5.1.7.

Any ideas or am I just screwing something up?

Kris Asick

Without seeing any code, here's what I suggest you do to begin debugging this.

First, you need to determine if the problem is visual, or if the numbers themselves are wrong. To do this, you'll need to write the mouse coordinates to the screen then take a screen capture while the mouse is at a particular coordinate, then see if the coordinate on-screen links up with the actual coordinate using a drawing program that can provide you with cursor coordinates.

If the numbers are right but the graphics are wrong, then you're probably doing transformations somewhere and are forgetting to go back to using the identity transformation following.

If the numbers are wrong, then the graphics are probably being rendered correctly, you just have some kind of error cropping up in the mouse handler.

Or, maybe there is some bug with 5.1.7 that's causing this, like maybe if you're running windowed, the identity transformation is pulling its data from the full size of the window instead of the active drawing area, which it shouldn't be doing. If that's the case, you can probably compensate using the transformation functions to create your own identity transformation to use for the time being.

sethhope

I found the source of the problem, however, I don't know how to fix it. I have a menu at the top of my screen (just a simple file menu). If I don't draw the menu, everything seems fine. I did as you suggested and measured the pixel offsets. It appears that, while the menu is drawn, at the top of the screen, the Y coordinate is spot on. As I progress, the dot drifts away from the mouse until, at the bottom, the distance between the mousey and doty is equivalent to the size of the menu from the top of the screen to the bottom of the native menu bar. I'm not sure if this is a bug with allegro 5.1.7 or not, but even if it is, I'd think there'd be a workaround.

[EDIT] I have a somewhat usable workaround for now. If I multiply mouseY by 1.025, it seems to fix the issue. This however uses the magic number of 1.025. If there is a solution other than this, I'd appreciate it. :)

Thomas Fjellstrom

Is this a menu you are drawing and implementing yourself? Or is it a OS menu?

If it's an OS menu, are you using allegro's built in support for showing one? If not, there may be some shenanigans needed to get allegro to know about it, and possibly ignore it.

If its your own menu, I honestly don't see how it would have any effect what so ever unless you're messing with the transformation.

sethhope

It's an os menu by using allegro's built in functions.

Thomas Fjellstrom

Ah, hmm. I'm not sure.

Are you messing with the transformations?

sethhope

I haven't touched the transformations. It appears to be a bug with Allegro 5.1.7... I just want to be sure that there isn't a flag that I should be setting (I read through the doc and can't find anything)

Thomas Fjellstrom

Yeah, it may be a bug in allegro. but I think we'd still like to see the smallest example you can make that has this problem.

sethhope

No problem!

#SelectExpand
1#include <iostream> 2#include <allegro5/allegro.h> 3#include <allegro5/allegro_native_dialog.h> 4#include <allegro5/allegro_primitives.h> 5 6//COMPILED WITH ALLEGRO 5.1.7 TO DEMONSTRATE MOUSE BUG 7 8int main(int argc, char** argv) { 9 ALLEGRO_DISPLAY* display = NULL; 10 ALLEGRO_EVENT_QUEUE *event = NULL; 11 ALLEGRO_TIMER *timer = NULL; 12 13 bool redraw = false; 14 int mouseX, mouseY; 15 if(!al_init()) 16 { 17 return 1; 18 } 19 if(!al_install_mouse()) 20 { 21 return 2; 22 } 23 timer = al_create_timer(1.0/60); 24 if(!timer) 25 { 26 return 3; 27 } 28 display = al_create_display(1024, 800); 29 if(!display) 30 { 31 return 4; 32 } 33 34 al_set_target_bitmap(al_get_backbuffer(display)); 35 al_clear_to_color(al_map_rgb(0,0,0)); 36 event = al_create_event_queue(); 37 if(!event) 38 { 39 al_destroy_display(display); 40 return 5; 41 } 42 if(!al_init_primitives_addon()) 43 { 44 return 6; 45 } 46 if(!al_init_native_dialog_addon()) 47 { 48 return 7; 49 } 50 ALLEGRO_MENU *menu = al_create_menu(); 51 ALLEGRO_MENU *menu_file = al_create_menu(); 52 al_append_menu_item(menu, "File", 0, 0, NULL, menu_file); 53 al_set_display_menu(display, menu); 54 al_register_event_source(event, al_get_default_menu_event_source()); 55 al_register_event_source(event, al_get_display_event_source(display)); 56 al_register_event_source(event, al_get_timer_event_source(timer)); 57 al_register_event_source(event, al_get_mouse_event_source()); 58 al_flip_display(); 59 60 al_start_timer(timer); 61 while(1) 62 { 63 ALLEGRO_EVENT ev; 64 al_wait_for_event(event, &ev); 65 if(ev.type == ALLEGRO_EVENT_TIMER) 66 { 67 redraw = true; 68 } 69 else if(ev.type == ALLEGRO_EVENT_MOUSE_AXES) 70 { 71 mouseX = ev.mouse.x; 72 mouseY = ev.mouse.y; //...*1.025 cancels out the bug if inserted at the end here. 73 } 74 else if(ev.type == ALLEGRO_EVENT_DISPLAY_CLOSE) 75 { 76 break; 77 } 78 if(redraw) 79 { 80 al_clear_to_color(al_map_rgb(0,0,0)); 81 al_draw_circle(mouseX, mouseY, 2, al_map_rgb(255, 255, 255), 2); 82 al_flip_display(); 83 } 84 } 85 return 0; 86}

Arthur Kalliokoski

I tried it, and the dot eventually got to where the mouse pointer was without any correction. But it lagged so bad I took another look, and there's nowhere that redraw gets set to false, so I put it at the end.

    if(redraw)
    {
      al_clear_to_color(al_map_rgb(0,0,0));
      al_draw_circle(mouseX, mouseY, 2, al_map_rgb(255, 255, 255), 2);
      al_flip_display();
    }
    redraw = false;
  }
  return 0;
}

Now it only lags behind a few pixels if I move the mouse fast enough.

sethhope

oops. Made the demo in 5 minutes and missed the redraw=false. xD Well, even with that there, the circle NEVER gets to the mouse. Could it have to do with the fact that I'm using Win 7 64 bit?

Arthur Kalliokoski
sethhope said:

Could it have to do with the fact that I'm using Win 7 64 bit?

I'd say it has to be one of the tools in the chain, probably the compiler used for main() or possibly the libraries. What compiler are you using etc?

sethhope

I'm using MinGW GCC 4.7.2 32 bit with allegro 5.1.7 md debug libraries built with the same compiler.

Arthur Kalliokoski

Anybody else have some other Windows system set up to test? My windows drive is sitting up on the shelf again.

Edgar Reynaldo

I can verify the mouse position is off by a small factor. The real mouse y position is larger than the event mouse y by a very small factor, such as the 1.025 suggested by sethhope. It is in sync near the top, and the difference grows the lower the mouse is on the screen. The x position appears accurate.

Also, the problem disappears when this line is removed :

al_set_display_menu(display, menu);

Also also, in fullscreen mode the mouse y is only off by a fixed amount appearing lower than event mouse y except near the very top of the screen. But the menu doesn't show up in fullscreen, so I don't know why you would do it that way.

Thomas Fjellstrom

Makes me think that the menu causes the 3d surface to be squashed. Which would cause a small error like that.

Edgar Reynaldo

Maybe it has to do with the factor of the window's height with the menu to the height of the window without it? x + 20 / x ?

Thread #614142. Printed from Allegro.cc