Non-linear pointer speed

While RISC OS allows one to adjust the mouse speed, this simply means one has the choice of high precision while giving yourself RSI when crossing the entire display area, or rapid movement across the display area but lousy precision.

Nick Jarman’s MouseScale module (!Scaler) implements pointer acceleration, so that when you are continually moving the mouse the effective speed increases. As a consequence, having the mouse on the minimum speed gives you the maximum precision, but without the RSI penalty. MouseScale was first implemented in 1991, and I’ve been using it since about a year after that.

So far, there isn’t a version that works on 5.23.

It’d be nice to implement this at the OS level, together with extra mouse configuration to enable/disable the acceleration.

I’ll second that, considering the huge size of desktops we’re now seeing.

I suspect !Scaler fails on 5.23 as it’s possibly touching the Page Zero mouse values directly.

Hopefully this could be done at the same time as the larger pointer whilst moving, that has recently been requested. Anyone fancy the challenge?
I’d suggest a stand alone app then submit it for OS integration.

Hopefully this could be done at the same time as the larger pointer whilst moving

The problem there is the internal RISCOS limit of 32×32 pixel pointers. It requires some underlying changes to the way pointers are handled before large pointers would be possible.

If someone would like send me a copy of !Scaler, I’ll debug it and find out what it’s doing. If it is poking around in Page Zero, we can either see if there’s another means to do it, or propose a code change to allow it to be done legally. That’s no guarantee it will happen, but I’m happy to take a look.

As luck would have it, I’m deeply entrenched in pointer stuff at the minute for the next release of ADFFS.

If someone would like send me a copy of !Scaler,

I think the version on the ARMClub 32 bit conversions page is probably the most recent.

According to the help it detects the version of OS and refuses to run on non-compatible OS versions.

As I suspected, it’s modifying MouseX, MouseY in Page Zero.

The problem there is the internal RISCOS limit of 32×32 pixel pointers. It requires some underlying changes to the way pointers are handled before large pointers would be possible.

I wonder how the RISC OS 3 app that enlarged the pointer did it! I’ll upload a copy to our website tomorrow in case anyone wants to have a look.
n.b. How big is a standard pointer?

How big is a standard pointer?

Appears to be 12×22 so plenty of room for enlargement.

I wonder how the RISC OS 3 app that enlarged the pointer did it! I’ll upload a copy to our website tomorrow in case anyone wants to have a look.

It will be writing directly to MEMC and VIDC at VSync. We could do something similar with GraphicsV 5 as it only specifies a max width of 32 (matching the VIDC limit), there’s no height limit. The height restriction is within OS_SpriteOp 36

We could replace OS_SpriteOp 36, add pointer scaling and allow larger pointers. To add acceleration, GraphicsV 5 needs intercepting and appropriate scaling applied before passing the call on.

I’d say it’s theoretically possible to create a Module, without modifying RISCOS. I will however look at the respective SWI’s and see if it’s easy to integrate into RISCOS, without breaking anything.