On 19/03/2020, at 08:22, Timothy Coltman <li...@maemagel.com> wrote:
> Same happens here, with my development version of RPCEmu, which is based on
> 0.9.2. The mouse doesn't seem to move at all, though the keyboard is fine
> (so I can exit back to full-screen mode). This is an iMac with 10.14.6.
The root problem is within quite strange (I'm being super polite here) mouse
handling code.
In mainwindow.cpp on non-follow-host mode, the strategy appears to be to try
and force the host mouse pointer into the centre of the window, then measure a
distance from that and pass it to lower layers. Lower layers appear to be
expecting only a difference since the last RISC OS position update though, not
a distance-from-centre, so things get out of hand quickly.
I can't honestly see how the non-follow-host code works on *any* platform and
have no idea how I ended up with a magic Mac binary that did. Perhaps it
requires a Qt build which *does not* properly support move-mouse-cursor, so
move-to-centre is ignored and the differential position logic calculates
correct positions by accident?
If I modify the code to allow follow-host mode in full screen, the most
noticeable issues are around the host mouse being able to move around the full
host screen area (e.g. 2560x1600 on this big screen in front of me) while the
RISC OS emulation might be set to something much smaller (e.g. 1024x768). This
means you can "move off the edges" of the RISC OS screen and have to move an
invisible host mouse pointer back into the 1024x768 region before the RISC OS
mouse picks up and starts tracking it again. RPCEmu simply does not attempt any
scaling between host and RISC OS mouse coordinates.
That bug aside, there is a lot of better stuff going on when follow-host is
used - not least being able to access the menu under macOS, including getting
at the window 'traffic light' controls which means you can exit full screen
without needing Ctrl+End - useful on any Mac laptop, since they don't have
"End" keys!
Source code alludes to bugs in follow-host mode that should give the user a
preference for turning this off, but at least on macOS the opposite seems quite
strongly true. So I've attached a patch:
* If you're in follows-host-mode ("mousehackon") it stays that way in full
screen
* The window pixel size is scaled to the RISC OS screen size so that the mouse
pointer boundaries work properly
* Added bonus, you can resize the RPCEmu window to scale the RISC OS desktop
within & the mouse still works
* Yes, I've accounted for EX2/EY2 doubling logic so e.g. mode 12 or mode 9 work
fine
I note with a little sadness that the internal VIDC emulation does not appear
to have a proper concept of eigenvalues and basically hacks EX2/EY2 using
hard-coded logic and pixel dimension thresholds. This makes it prohibitively
difficult to implement correct mouse pointer behaviour in EX0/EY0 modes, which
is a shame. A full screen mode on a Retina Mac in EX0/EY0 would be a
realisation of a dream we had at Acorn way-back-when we did the whole EX0
sprites support stuff in the first place.
This patch conflicts on one hunk with your V4 macOS patch, Tim, so mine
includes an equivalent change in itself allowing the macOS patch hunk in
question to fail safely. Apply this first, then your Mac patch.
The ROOL USB stick build will include all this.
--
Andrew Hodgkinson
RISC OS Open Limited
https://www.riscosopen.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
