Mouse Pointer scaling and options

Currently, the Wimp’s setptr_shape routine doesn’t set scaling factors and as a consequence the Mouse Pointers are scaled on a Mode change, which can result in some nasty looking mice pointers, for example:

F12
BASIC
MODE 13
*POINTER 1

…looks awful. If you then turn the scaling off via:

DIM Z% 16:!Z%=1:Z%!4=1:Z%!8=1:Z%!12=1
SYS "Wimp_SpriteOp",36,0,"ptr_default",1,0,0,Z%,0

…it looks a lot better.

Could I propose an option be put into Configure\Mouse to allow the user to optionally specify this scaling factor, allowing the cursor to be made bigger in high res modes, or simply turn scaling off?

And whilst we’re there, why not allow the ptr_default sprite to be selectable in Configure/Mouse, so the pointer style can be changed by the average user?

Same goes for the Hourglass.

And whilst we’re there, why not allow the ptr_default sprite to be selectable in Configure/Mouse, so the pointer style can be changed by the average user?

Couldn’t you just *IconSprites a replacement?

Very user friendly ;)

I don’t personally have a need to change the Pointer, but its fairly standard for a Windows based environment to allow the user to change the Pointer through the GUI and probably something we’d want to add to RISCOS at some point.

I do find the scaling offensive though, as I have to look at squashed cursors all day when testing games that use MODE 9, 13, 15 and 48

With many more RISC OS users now using hi resolution modes 1920×1080 and above, losing the pointer can be a big problem (none of our eyesights are getting any better!)
There used to be a utility that would dynamically enlarge the pointer as you moved it shrinking it back down when you slowed or stopped moving. I don’t think it was ever 32bitted.
If someone was to do any work on pointers it would be great if this could be added at the same time! I’d like it to default to on! Others may disagree!

The above reminds me of:
This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody’s job. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn’t do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have.

I thought that as well Chris and even tested it before posting, however when I tried scaling the cursor up on the Pi the bottom was getting chopped off.

I’m not sure if that’s a software or hardware limit – I suspect hardware (32×32 perhaps?). For a large pointer it may require a switch to a software pointer.

Repro:

F12
BASIC
MODE 28
DIM Z% 16:!Z%=2:Z%!4=2:Z%!8=1:Z%!12=1
SYS "Wimp_SpriteOp",36,0,"ptr_default",1,0,0,Z%,0

I’m not sure if that’s a software or hardware limit – I suspect hardware (32×32 perhaps?)

It’s a software limit. The kernel (and wimp/SpriteExtend?) have a max pointer size of 32×32. As a consequence most of the GraphicsV drivers also work to a max size of 32×32 (in particular they’ll have a max width of 32, due to the pointer data always being padded out to 32 pixels wide).

It’ll get fixed eventually.

I (well Andrew actually) found a copy of !Pointer on our server. As I thought it is not 32bit.
Its help file says:

This application dynamically alters the size of the mouse pointer. The size of the pointer is proportional to the speed at which the mouse moves; the faster the mouse moves the larger the pointer becomes. It will also cycle the colour of the mouse pointer or set it to a larger size to increase it’s visibility on the desktop.

At the end of the module it has.

Written by David De Vorchik Ideas from Stuart Payne and Paul LeBeau Thoughts from Chris Murray and Vorn Hancock. Broken by Tony Sumner, Charles Whyte and Phil Colmer. Abused by Tim Caspell and Alison Formstone. Thanks due to Kay Morris, Ian Johnson, David Roberts, William Stoye and Roger Wilson. Have fun… PARP!

With that long list it makes me think that it is not as easy as it might at first appear!

It’s a software limit. The kernel (and wimp/SpriteExtend?) have a max pointer size of 32×32. As a consequence most of the GraphicsV drivers also work to a max size of 32×32 (in particular they’ll have a max width of 32, due to the pointer data always being padded out to 32 pixels wide).

I was aware of the 32 pixel width restriction (which is clearly a throwback to VIDC), but wasn’t aware of the height having the same restriction. That could be removed couldn’t it, without ill effect, or are there hardcoded data size limits? I suppose it depends on how the Pointer memory buffer is allocated before its passed to GraphicsV – the buffer being available for the duration of the Pointers life.

What is actually clipping the Pointer Sprite to 32 pixels high when it’s rescaled in my Repro above? OS_SpriteOp, GraphicsV or some internal function?

Anyone know what the hardware restrictions are post VIDC20? GraphicsV might need extending to be aware of those limits at driver level, so the OS can query and not scale the Pointer over the drivers limits.

If one was to intercept the relevant OS_SpriteOp and call GraphicsV directly, the OS height restriction could be worked around easy enough. I’m doing something along those lines to emulate a VIDC hardware pointer, although opted for a software pointer as I suspected most hardware pointers would not support the full screen height pointer that Caverns required.

Off topic slightly, I’m already intercepting OS_SpriteOp’s and massaging the scaling register value, as back in the day (and in the PRM example), scaling could be unspecified with a value of -1, this crashes RO5 badly as it only accepts 0 (as per the SWI documentation.) You’d be amazed at how many games developers copied the PRM example and didn’t read the SWI documentation, close to 100% so far of the games I’ve seen using OS_SpriteOp!

I think I’ll extend it and actually force a scaling factor on route to the OS to solve my particular “retro gaming mouse pointer” issue.

It’ll get fixed eventually.

That could be removed couldn’t it, without ill effect, or are there hardcoded data size limits? I suppose it depends on how the Pointer memory buffer is allocated before its passed to GraphicsV – the buffer being available for the duration of the Pointers life.

Brains larger than mine have already written about this in the proposed graphicsv enhancements page, which you could look at

AIUI most if not all RISC OS ports use hardware pointers. I would expect the maximum pointer size to not necessarily be the same on all hardware.
Ex broadcom engineers recently on the Pi forums (when confirming that the Pi pointer hardware didn’t cope with screen widths greater than 2048) did talk of having a pointer hundreds of pixels wide! Not sure what the height restriction is.

Also I believe Raspbian on the Pi has only just had a hardware cursor support added and that many(most) other OS/hardware systems (e.g. windows) do not use a hardware pointer. The smoothness of the pointer on RISC OS is something I hate losing when I have to use Windows!

The smoothness of the pointer on RISC OS is something I hate losing when I have to use Windows!

In the next release of ADFFS, I’ve moved from a hardware pointer to software one to get around the 32×32 size issue – you certainly notice the difference. Hardware is definitely preferable if it will support it and only fall back to software as a last resort.

If/when RISCOS can support a hardware pointer of 32×256 I’ll switch back to hardware.