Big Mode on ARMBook (aka ARMBok) - developers please check your software

Has anyone else noticed problems with pointers when using ‘Big Mode’?

If you look closely at applications where the pointer is changed from the default blue arrow to something else (using the icon validation string P<spritename>), then often the changed pointer is incomplete.

In many cases here it is the top part or top left which is displayed.

Using Paint: start Paint and click on the icon, which opens the Create new Sprite window. Move the mouse over the name or dimensions fields, and the pointer changes to a blue I … is the bottom bar of the I visible?

Using Edit: Open an Edit window and press F3 to open the Save As window. Again, when the mouse is over the name field, is the I pointer complete?

This effect has been seen on several applications, and is more noticeable the larger the pointer is. For example, the Auto Scroll icon ptr_autoscr is 31×31, which is nearly the maximum of 32×32. Only the upper left quadrant of that is displayed!

I can find no trace of 180dpi sprites for these standard pointers … but when I made one it did not have the desired effect.

My suspicion is that the displayed sprite is being clipped to 32×32, and it is not being adjusted for EX0 EY0 modes.

I do have a small test program to illustrate the problem, but I would be grateful if someone else can confirm that they see the problem as well.

I initially thought this was a problem with my application, but I now suspect it is a Wimp bug as it is visible on other apps as well. If you look closely, I think that even the standard default arrow pointer has a truncated tail!

Hi Martin,
Just tried it on a RPi and get similar here. Using the basic SD image from the RPi downloads page.
Tail is truncated. Also HON produces an hourglass of the original size, not scaled up like the pointer.

Has anyone else noticed problems with pointers when using ‘Big Mode’?

Does this help

I have just given myself a quick reminder, F12 after iconsprites ...sprites11. That gets a complete pointer of the right size here.

My suspicion is that the displayed sprite is being clipped to 32×32

Correct. Some OS + driver updates are needed to support larger sizes.

Whilst I’ve seen the effect described, I was going to say that I haven’t seen it on ARMBook (although I may have just not noticed). However, BigMode on ARMbook does do a bit more than just switching to the mode (for a start it makes sure that a wide range of suitable gfx are loaded etc, both on entry and exit). So, as David says, it is quite possible that being festidious about ensuring all the right gfx helps with this.

On ARMBook, the resulting effect is to basically move as much of the desktop as possible to 180dpi for better visuals, as well as making everything bigger. After all, if you’re going to go high-dpi, you may as well maximise your enjoyment of it ;)

@Stephen: Thanks for the confirmation, and the note about the horglass.

@David: Thanks for the link further up this thread – somehow I missed that.

@Jeffrey: Thanks for the comfirmation the pointers are clipped to 32×32.
Do you know if the necessary changes on ROOL’s list, or should a request be made?

@Andrew: Althought I accept your changes will include more than just EX0 EY0, it was an ArmBook user who alerted me to the very strange and misleading pointers from my application!

After these hints, I have indeed found in !ThemeDefs there are Sprites11 files which include 180×180dpi pointer definitions. However, presumably to avoid the clipping, they are all their original pixel sizes. This means that when in use they are to my eye rather too small – eg the write pointer is smaller than the text written!

As far as application specific pointers, I think that they need to provide two files – say ptr11 and ptr22 – containing 180dpi and 90dpi pointers respectively (but with the same pixel size), and arrange to do an *IconSprites ptr initially, and when a EX/Y mode change is detected. They may appear rather small in Big Mode, but at least they will be complete!

Incidentally, ptr_confirm seems to be defined in Sprites & Sprites22 as 25×25 pixels in mode 8 (ie 90×45 dpi) and in Sprites11 as 25×25 pixels, 180×90 dpi. This has the effect that in normal modes and Big Mode only the top two thirds is displayed, as it is then clipped!

@Jeffrey: Thanks for the comfirmation the pointers are clipped to 32×32.
Do you know if the necessary changes on ROOL’s list, or should a request be made?

It’s on the list

Since RISC OS 5, the OS has shipped with 180dpi icon sprites (aka Sprites11), but not all applications do. Also, some applications may make assumptions based on 90dpi when plotting text or sprites.

We’d gently ask any current developers to please check their software in 180dpi screen modes, and (if necessary) make updates available. To check this, it is very easy as follows:

1) Press menu over the Display Manager in the bottom right hand corner of the screen.
2) Slide to the right off “Mode” and you’ll see the mode-string displayed for the current mode.
3) It may end in EX1 EY1 – if so, change this to EX0 EY0. Otherwise add " EX0 EY0" (no quotes) on the end.
4) Press return.

You’ll now be in the same resolution as you started, but at 180dpi. This will cause everything to look larger, but also much nicer (eg. text/font rendering).

When I try this in RPCEmu, the mouse pointer is constrained to a small rectangle in the bottom left corner of the screen and the clicks don’t seem to line up with the things I try to click on. Presumably this is a mouse emulation issue rather than an OS issue? I’m running RPCEmu in Linux.

To be fair I haven’t got around to updating my RPCEmu version in a long time.

@Jeffrey:

It’s on the list

Thanks. An interesting (re)read. I see that it is a complicated area, and has been on the list for a long time! I won’t hold my breath.

Presumably this is a mouse emulation issue rather than an OS issue?

That’s been around for a long time (at least since 0.8.14) and it’s still present in RPCEmu 0.9.1. I did log it here but I couldn’t mention it on the RPCEmu mailing list because the mailing list won’t accept iCloud email addresses :-(

P.S. EX1/EY2 modes are also affected (the mouse pointer appears above where it should be).