Mouse integration in Archimedes emulators

[ccawley2011]

What would be the best way of implementing mouse integration in an Archimedes emulator? I'm currently looking into how to improve the mouse support in ArcEm, which currently doesn't handle mouse input very well. The best thing that I've been able to come up with is to use the position of the cursor sprite and using values relative to that for mouse movements, but I don't think there's any way of retrieving the hotspot coordinates, meaning that the resulting mouse position is slightly off.

Any suggestions?

[IanJeffray]

I don't think there's any way of retrieving the hotspot coordinates

You could assume/probe for it being RISC OS that's running in the emulator, then pull the hotspot out of zero page. Grim.

You could use some heuristics based on cursor size/shape to "detect" when it's a pointer, and then assume the hotspot is topleft, or "anything else" is probably hourglass and just centre the hotspot (this will also happen to work for things like the caret-cursor).

Or you could just not care about the hotspot and always have it top left, because it's not that important to have the hourglass/etc centred.

If you can sort it all out to do the gross mapping of true host position of the mouse over the window to logical mouse position in the emulated OS, that'd be marvellous. This is an issue with all emulators and VMs and IMO it always feels better when this mapping is done, rather than trying to 'capture' the host mouse and then pretend any emulated movement is a relative move.

EDIT: Another probably crappy idea - a little RISC OS module that pushes the hotspot to the emulator (hw space) every Vsync.

[davidb]

Have you looked at RPCEmu and Arculator? RPCEmu, at least, lets you configure the way the mouse is handled.

[ccawley2011]

You could use some heuristics based on cursor size/shape to "detect" when it's a pointer, and then assume the hotspot is topleft, or "anything else" is probably hourglass and just centre the hotspot (this will also happen to work for things like the caret-cursor).

Or you could just not care about the hotspot and always have it top left, because it's not that important to have the hourglass/etc centred.

Unfortunately, the hotspot for the default mouse pointer isn't located at 0x0, which is what causes the mouse position to be incorrect.

Have you looked at RPCEmu and Arculator? RPCEmu, at least, lets you configure the way the mouse is handled.

I've looked at RPCEmu, and it looks like it's handled there by intercepting SWI calls from the guest operating system. Arculator doesn't seem to have any equivalent to "Follow host mouse", and just supports mouse capture.

[IanJeffray]

Unfortunately, the hotspot for the default mouse pointer isn't located at 0x0, which is what causes the mouse position to be incorrect.

Oh hah. Amusing. Well a heuristic-based approach would still work for that. I wonder why it's not at the left.

[sirbod]

You probably want a helper Module that replies to PointerV 0 calls with the absolute coordinates of the mouse, or hook into MouseV.

[Phlamethrower]

EDIT: Another probably crappy idea - a little RISC OS module that pushes the hotspot to the emulator (hw space) every Vsync.

I think a helper module is probably the best way of doing things:

• If you a build a system that relies purely on the location of the pointer image, it won't work if the image is detached from the mouse, or if the image is disabled (flight sims, FPS, etc.). IIRC some games/demos also use the pointer image as a general hardware sprite, completely unrelated to the mouse.
• I believe the main way RPCEmu does things is by having CPU emulation directly intercept several mouse related SWIs and overriding them, which can cause compatibility issues with some software. For the Arc I'd imagine this would be worse since some games might not use the SWIs and instead peek the hardware or kernel workspace directly.

A module which does things using legal OS calls (or pokes around in kernel workspace for situations where calls aren't available), and uses special SWIs or IO addresses to pass information between the OS and the emulator should be better. It'd provide a framework to allow similar helpers to be implemented for other guest OS's (Linux, RISC iX, etc.), and allow for easy implementation of extensions like scrollwheel support.

You probably want a helper Module that replies to PointerV 0 calls with the absolute coordinates of the mouse, or hook into MouseV.

PointerV is a RISC OS 3.5 addition; for earlier OS versions I think the mouse driver was directly implemented in the kernel.