OS_SpriteOp 3 always changes MODE

OS_SpriteOp 3 is only supposed to change screen mode if the Sprite mode differs from the current mode, but it appears to change regardless. It looks like this is a long standing bug introduced in RISCOS 3.5, probably as a result of the switch to mode selectors in the mode check code.

I noticed this whilst testing Enthar Seven, which switches to mode 12, writes text to the screen and then *ScreenLoad’s a sprite that doesn’t fill the screen. Tested on RISCOS 3.5, 3.71 and 5.25 on RiscPC.

Since RISC OS 3.5 the code certainly has been a bit busted

Numbered modes where the sprite size doesn’t match the screen size is a bit of a tricky one, since the kernel will try to use a mode number even if the screen isn’t in a numbered mode (so the dimensions of the mode in the sprite header might not match the dimensions of the sprite). (Also a quick test on my Iyonix has failed to get that code to do what I’d expect, so maybe that code is a bit broken as well. Actually, *ScreenSave seems to be a bit broken in general, since I’ve just had it save out a couple of sprites of mostly &ff. Uh-oh!)

I guess for ScreenLoad, I could amend the logic so that if it hits this case it’ll avoid doing the mode switch if it’s already in the mode that the sprite header indicates. That’ll reduce the number of unexpected mode changes, but not eliminate them (since the OS can’t tell the difference between a sprite that’s intended to only fill part of the screen and a sprite where the mode number was obtained by downgrading a mode selector block)

One would hope (at the risk of sounding like someone should be writing code to make *ScreenLoad work better in 2018, which I’m not), that if the mode number and dimensions matched a numbered mode the OS can display, it would honour the mode number… otherwise just the format.

And I think I’d prefer a depth-correct version of my current mode, rather than different geometry… but I’m an emulator user so I may be atypical.

What struck me as odd was the fact it’s checking the Sprite dimensions instead of the Sprite mode dimensions against the current screen mode. It appears to be making the assumption the Sprite should fill the screen, when in fact the Sprite is plotted at the bottom left of the graphics window and isn’t scaled.

It’s not something that needs fixing any time soon, it’s gone unnoticed for 24 years.

I forgot to mention, doesn’t the Sprite mode word in 3.5 onward kind of break *ScreenLoad / OS_SpriteOp 3 as it only specifies DPI and not the explicit mode resolution.

In my mind, DPI is a resolution independent means of printing to scale and little to do with specifying a screen resolution!

There is some conflict with ‘dpi’. The OS supports a couple of options (45/90/180) to describe pixel size, but reprographic software has often used real-world resolutions (300/600/1200) which one would not expect a screen to support.

Whether you want a 1200dpi sprite to display at ‘actual size’, or 1:1 pixels, depends on what you’re doing with it – dropping it onto a page, real size; loading into a sprite editor, 1:1. As for loading such a sprite on the screen, who knows.

In my opinion it was a mistake to have ScreenLoad support both (a) loading to arbitrary graphics windows, and (b) changing screen mode to the mode specified in the sprite. If it only supported one of those (or there was a way of indicating which behaviour you wanted) then there wouldn’t be any room for ambiguity.