Return sprite mode word for a given set of mode variables

I was scratching round in OS_ScreenMode and OS_SpriteOp expecting that this already existed, but it seems not.

Given the ballooning number of valid modes supported (which is a good thing) mapping those to the corresponding sprite mode word has got rather cumbersome, especially when trying to ensure the lowest compatible mode word (ie. degrade to RISC OS 3.5 type if possible, and degrade to numbered mode per PRM5a-117 if possible).

It’d be handy to have a SWI that takes the NColour/ModeFlags/Log2BPP which I think definitively describes the screen format, and transform those into whatever sprite mode word would best describe it in the most compatible way (or error if not possible). Using OS_ReadModeVariable pretty much any mode (not just the current one) could be mapped without needing lots of repeated logic, so at least if the OS got it wrong there’s only one place to fix.

Some backwards compatible care might be needed: for example if !Paint used this there’d need to be a fallback for OS’s without the SWI. Or perhaps bung something in CallASWI, the dumping ground for all OS_ SWI extensions?

This is close to what Martin Bazley requested a while ago, but I haven’t got round to implementing yet: a SpriteOp to return the amount of memory needed to store a sprite for a given set of width/height/mode/mask/palette parameters. My idea was to have the call accept any mode specifier as input, and return the sprite mode word (or all the parameters from the sprite header?) as output, so that it can do double-duty of calculating memory size and converting modes to sprite mode words. This functionality roughly matches what’s offered by the kernels internal PreCreateHeader routine (look at CreateHeader for usage), so it should be pretty straightforward to modify it and expose it via OS_SpriteOp if you feel like giving it a go.

Some backwards compatible care might be needed: for example if !Paint used this there’d need to be a fallback for OS’s without the SWI. Or perhaps bung something in CallASWI, the dumping ground for all OS_ SWI extensions?

OS_SpriteOp is vectored, so it would be pretty trivial to have CallASWI sit on the vector and provide backwards-compatibility that way.

This is close to what Martin Bazley requested a while ago, but I haven’t got round to implementing yet

At least it wasn’t just that I couldn’t find it! Taking a mode specifier would also make sense, a bit like ColourTrans lets you pass in R0. I’ll at least write it on my todo list, but it’s somewhere on the radio horizon.

My idea was to have the call accept any mode specifier as input, and return the sprite mode word (or all the parameters from the sprite header?) as output

A return register set that handily matched the input for OS_SpriteOp 15 would be useful (except R2 of course).

OS_SpriteOp is vectored, so it would be pretty trivial to have CallASWI sit on the vector and provide backwards-compatibility that way.

Good point, yes, that does make that aspect simple. Alternatively, it could be hosted in SpriteExtend (as Create/remove palette is) which already has a disc loading version for RISC OS 3.50 at least.

Taking a mode specifier would also make sense, a bit like ColourTrans lets you pass in R0. I’ll at least write it on my todo list, but it’s somewhere on the radio horizon.

I think I might have talked myself out of this, since having done a bit more digging it seems OS_SpriteOp 15 already accepts a mode specifier (as well as a BBC-style mode number, as well as a RISC OS 3.50 sprite word).

Either way I’d need to construct a mode specifier, for example for a 180 dpi 32k colour RGB format the minimal set of mode variables in the mode specifier might be

DIM mode% 48
mode%!0=1  :REM Mode specifier
mode%!4=2
mode%!8=2  :REM 2×2 pixels
mode%!12=4 :REM Pixel depth
mode%!16=-1:REM Any frequency
mode%!20=4 :REM X eigenfactor
mode%!24=0
mode%!28=5 :REM Y eigenfactor
mode%!32=0
mode%!36=0 :REM Mode flags
mode%!40=1<<14
mode%!44=-1:REM End of list

then if I want the sprite mode word per my wish list then I just make a teeny sprite, say 2×2 pixels, the size doesn’t really matter since I’ll chuck it away once I got the result I want

DIM area% 16+44+(2*2*4):REM Area + sprite header + 2×2 pixels
area%!0=16+44+(2*2*4)
area%!8=16
SYS"OS_SpriteOp",256+9,area%:REM Init area
SYS"OS_SpriteOp",256+15,area%,“test”,0,2,2,mode%:REM Create with no palette
SYS"OS_SpriteOp",256+40,area%,“test” TO,,,,,,type%:REM Read info
PRINT"Sprite mode word is ";~type%

with the added benefit that these 5 lines work on any OS already.