|Re: [hatari-devel] Synching host mouse position to Atari mouse position|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
This is a multi-part message in MIME format.
On 11/4/19 11:57 AM, Thomas Huth wrote:
Am Fri, 1 Nov 2019 00:09:45 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
I did small patch inspired by recent OSEX header being added to
EmuTOS to support for synching host mouse position with TOS mouse
position for Aranym...
Attached patch syncs host mouse to Atari mouse position whenever
mouse enters Hatari window and when window resolution changes.
It requires line-A base to be known, which is the case when
cartridge code is used, i.e. either GEMDOS HD or VDI mode is
enabled (and that user hasn't disabled mouse warping).
Otherwise things are as earlier.
Is this something I could push to Hatari, or is not working
without GEMDOS HD or VDI emulation too strange for users?
Looks dangerous. If a program takes over the full memory and uses its
own mouse handler, you might get completly wrong values from the ST
I'm not so concerned about programs overwriting those line-A
variables, but TOS interrupt handler for updating them being
Fortunately majority of demos use just keyboard, and games
Of those that use mouse, how common it's for them to use their
own mouse handler? And more importantly, could it be detected
so that warping can be (temporarily) disabled?
Are there any non-demo/non-game programs which would have their
own mouse handler, e.g. Cubase and its RTOS?
Nicolas, you've fixed IKBD emulation for some demos, any
comments on detecting changed mouse handler?
If we really want to include such a thing (I'm really not sure
whether we should), you need to add more sanity checks here (e.g.
whether x and y is within range of the display)
Attached is updated patch which does that check and also fixes
issues with the (already existing) mouse warping done on
I changed warping to be done only when Hatari has/gets keyboard
focus. This fixes bad warping for Hatari windows that are covered
by other windows, when using click-to-focus windowing policy.
I couldn't come up any way to fix it for focus-follows-mouse
windowing policy, as there's no portable method for finding out
whether Hatari window is fully visible, so I just documented
that in the manual page.
and maybe also add an option to disable this feature.
It's behind the already existing --mousewarp option, which
is enabled by default.