Sounds like a bug.

You don't, but we should. This is a bug in Allegro, but I thought I'd fixed it a while back. Maybe it got reintroduced in some later patch because it had undesirable side-effects.

What system/Allegro version are you using? I'll try if I can reproduce and fix the problem here. I can probably use the exmouse example to do the testing, but if you have a small testcase programme I can compile and run, that might be helpful.

Oh, one suggestion: use load_bitmap() instead of load_bmp().

load_bitmap can load all kinds of bitmaps Allegro can load natively (BMP/LBM/PCX/TGA) plus all formats registered to it (by addons for example).

load_bmp can only load .BMP files.

Maybe I'm not a good C programmer but I can see in your code many bugs.

If it's true it doesn't change the focus because of an Allegro's bug, you can solve it like this:

Think this is the screen, where point P represents where mouse_x and mouse_y are; point X is where you would like mouse_x and mouse_y to be. Then you must add to Px and Py necessaries pixels.

+--------------------------------------+
|
| .[P]
| .[X]
|
|
+
...

Before writing the code I must advise you to control all your variables before using them. Obviously you won't see your mouse until you move it, because you haven't initialised it before entering the while loop.

You ought not to call show_mouse() if it isn't necessary.

This is the code I'd write:

No, if it's a bug you report it or try to help fix it, not work around it. That said, I haven't had time to look into it yet.

That said, the extra show_mouse() within the loop is definitely redundant and will probably produce much poorer behavior than if it were removed. You also should only change the mouse sprite if you really want to change it, not at each iteration of the loop.
None of those bugs would cause the problem you're seeing though.

EDIT:
Can you try the following: open allegro/src/win/wddraw.c and find the function gfx_directx_show_mouse(). Add ShowCursor(TRUE) after SetCursor() so that the function now looks like

/* gfx_directx_show_mouse:
 *  Switch the Windows cursor to a hardware cursor
 */
int gfx_directx_show_mouse(struct BITMAP *bmp, int x, int y)
{
   if (hcursor) {
      _win_hcursor = hcursor;
      SetCursor(hcursor);
      ShowCursor(TRUE);
      return 0;
   }

   return -1;
}

and recompile Allegro.

For good measure and if this works, you should probably also change gfx_directx_hide_mouse() like so:

/* gfx_directx_hide_mouse:
 *  Hide the hardware cursor
 */
void gfx_directx_hide_mouse(void)
{
   _win_hcursor = NULL;
   SetCursor(NULL);
   ShowCursor(FALSE);
}

Ah soryy, I forgot to comment about the mouse sprite focus.
The code is a little messy (well, that's putting it mildly) but it looks liek it actually should work. Try calling set_mouse_sprite_focus() before set_mouse_sprite() and see if that helps. You can also try explicitly hiding and redisplaying the mouse. Let me know if that works.

About displaying the mouse, the code I posted above was an attempt to tell Windows to display the pointer. Apparently, however, Windows is too stupid (excuse me) to draw the mouse pointer unless the mouse moves. The attached patch is a hack that fakes a move event to work around the problem. I've already tested and submitted it.

I hope this isn't considered a 'thread hijack' (i'm not sure what is and is not considered a 'hijack'). But is there any performace gain out of setting a mouse pointer to an image you want and show_mouse-ing it to the buffer, rather than just doing a draw_sprite at mouse_x, mouse_y?

It's basically when someone takes a thread off the original topic... ahem

Thanks for your reply (I'm using show_mouse, right now. I was just curious as to the other technique!)