Update mouse movement handling:

[Chadnaut]

• Separate axis monitoring to prevent direction blocking
• Capture pointer movements outside the window to prevent lost directions
• Pointer no longer confined to threshold region

Basically changed ALL the MouseMoved handling - requires thorough testing!

[oomek]

While you're at mouse events would you please take a look at this PR? https://github.com/oomek/attractplus/pull/108/files

[Chadnaut]

I should have added that up front - this PR is specifically to fix that issue

• https://github.com/oomek/attractplus/issues/107
• https://github.com/oomek/attractplus/pull/108/files

[Chadnaut]

@oomek Why was this branch deleted?

[oomek]

I didn't

[oomek]

My fault. Restored, fetch

[oomek]

Testing. I've had no idea that the mouse pointer is locked to the centre of the screen when the mouse movement is bound to Up/Down controls. Looking good so far. Can you please explain the other issues it fixes, I'm not able to reproduce.

[Chadnaut]

1. The priority of the mouse moved event feels inconsistent

The old capture region is a small box in the center of the window. When the mouse escapes this box it triggers a direction, and the mouse is reset to the center.

If you move the mouse diagonally, it will hit one edge of the box before the other, then reset. For example, the "right" direction hits moments before the "up" direction, and all "up" progress is lost when reset.

2. If I spin the spinner too fast, it gets "stuck"

When the mouse is moved quickly it has a chance to escape the window. Although AM still tracks it, it doesn't trigger the capture region reset.

[Chadnaut]

To reproduce:

1. Set the mouse up/down to control game prev/next.
2. Move mouse up/right - but more right than up. "Right" triggers a cursor reset, causing to "up" to never register.
3. Mouse the mouse very fast to escape the window. Up/down no longer registers prev/next.