On 19/03/2020, at 08:22, Timothy Coltman <lists@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
No comments:
Post a Comment