SpriteOp help?

But still… documented.

So, essentially it was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard”. ;)

Why doesn’t stuff exist on archive.org, I hear you cry?

I’m tempted to point out that a pretty good job was made of removing movspclr from reality…

So, essentially it was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard”. ;)

My comment was rather that it was documented, albeit in a slightly different section than you might expect – but still with the Wimp documentation – unlike the equivalent documentation from Castle which was… not.

I’m tempted to point out that a pretty good job was made of removing movspclr from reality…

movspclr was contemporary of that time as I recall, and given Castle’s propensity for issuing cease and desists, I didn’t want the hassle. The content from movspclr was entirely transferred to gerph.org when I transferred to that domain. And of course the random junk that was on movspclr was moved to usenet.gerph.org which still exists and has a bizarre grab bag of things on it. These days, rather than putting things on a site like that I’m more likely to just create a git repository (for code, that is). Even if it’s just one file, it’s usually easiest to place things in a git repo and track them that way.

With the exception, of course, for the Pyromaniac specific resources which you can find on pyromaniac.riscos.online. And the presentations which are in presentations.riscos.online. And the build services, which is on build.riscos.online. And RailPro, which is on railpro.riscos.online. Oops. Just slammed two trains into one another.

Anyways, I think we’ve covered the horrible history of this, how are we going to make a felicitous future?

	size% += 4
	DIM area% size%
	!area% = size%
	area%!8 = 16

That’s it? Seems easy enough.

Um, is PutSpriteScaled provided by the SpriteExt module, by any chance?

Um, is PutSpriteScaled provided by the SpriteExt module, by any chance?

Any sprite rendering operation which doesn’t involve just copying bytes from one place to another is generally SpriteExtend in RISC OS Classic. Exceptions to this would be cases like ViewFinder’s original driver and VideoHWVF, which IIRC both had accelerated implementations which are used when rendering to the screen.

In the general case though, refer to the PRMs, chapter on Sprites, SWI definition for OS_SpriteOp which explicitly states which SWIs are handled by SpriteExtend.

In RISC OS Pyromaniac the vectored call is handled by the sprite subsystem, and then handed off to the graphics implementation as necessary.

That’s it? Seems easy enough.

Almost. See https://www.riscosopen.org/wiki/documentation/show/Format%20Of%20Sprite%20Area

Um, is PutSpriteScaled provided by the SpriteExt module, by any chance?

Yes, you’ll need the SpriteExtend module going to stand any chance of getting the Wimp up.

Yes, you’ll need the SpriteExtend module going to stand any chance of getting the Wimp up.

Actually not so much; the WindowManager ran for about half a year without any sprite operations implemented at all. There were one or two places in the WindowManager which didn’t cope with errors being returned but as I recall you could cope pretty well without sprites.

Filer running without any sprites:

TaskManager’s icon isn’t there, but it doesn’t care:

Those were all with every OS_SpriteOp call returning an error, so it copes reasonably well – as it should. I think there were only one or two calls that I had to make changes to.

It seems I have to extend what’s covered by OS_ReadModeVariable to cover ModeSelectorBlocks. Thanks for all the help, folks!

It seems I have to extend what’s covered by OS_ReadModeVariable to cover ModeSelectorBlocks. Thanks for all the help, folks!

OS_ReadModeVariable can take a whole load of things. See PRM 5a Video chapter for more details.

You will find the collected information about what is necessary for mode specification in https://pyromaniac.riscos.online/resources.html, API documentation archive, document ‘Graphics mode specification’.

Also the notes on slide 17 of my presentation on Pyromaniac – https://presentation.riscos.online/pyromaniac2/index.html

Thanks for that. There’s a new SpriteModeWord format from 5.21: w111 1ttt tttt 0000 ffff ffff yyxx 0001

https://www.riscosopen.org/wiki/documentation/show/Sprite%20Mode%20Word

Discussing the past and how we got here, is undoubtedly interesting, but it doesn’t take us forward.

Understanding what the API actually looks like does, though…

Various sources of information are cited. One stands out in particular: the ROOL wiki, as it is: the only one that can be freely updated, it’s freely available to everybody,

The StrongHelp OS Manuals fit those two criteria, too, don’t they?

That, and we’ve pretty much sorted the tracking of updates problem, too. We’re also not that far from having GitHub spit out new RISC OS-friendly Zip archives of the manuals when changes are committed.

Various sources of information are cited. One stands out in particular: the ROOL wiki, as it is: the only one that can be freely updated, it’s freely available to everybody

The StrongHelp OS Manuals fit those two criteria, too, don’t they?

Not nearly so well. The difference is distribution. As soon as the ROOL Wiki is updated, the changes are there for everybody to see and use. With SH, you have to put altered stuff back on a site (where is that? For the life of me I can’t remember, unlike here) and then hope that users will download it. Because you don’t use SH from a central repo, whereas with the ROOL wiki, you do.

Is it really so onerous to Google “StrongHelp manuals”? Or just bookmark https://www.riscos.info/downloads/stronghelp/manuals/ ?

Personally I prefer the manuals. While there are obvious benefits to a wiki, the online nature means that it requires an internet connection, a fetch for each thing to look at (which takes time), and a browser isn’t really great for having multiple things open at once (it gets a bit clumsy to use).

StrongHelp has one job to do, and it does it well and extremely rapidly. It’s my preferred API reference – especially wading through the crap that is in OS_Byte.

I only go to the wiki for stuff not in StrongHelp, as I’ll usually have my answer out of StrongHelp in less time than it takes to go to ROOL, click the “Documents” tab, enter “OS_Byte” into the search, get the results back, pull up the main list so I know which one I’m aiming for, click it for the details, click for more details…
…and then find the wiki doesn’t have a diagram of the keyboard or whatever, so end up looking at StrongHelp anyway.

The difference is distribution. As soon as the ROOL Wiki is updated, the changes are there for everybody to see and use. With SH, you have to put altered stuff back on a site (where is that? For the life of me I can’t remember, unlike here) and then hope that users will download it. Because you don’t use SH from a central repo, whereas with the ROOL wiki, you do.

I have left StrongHelpViewer lying around for much too long now (got stuck somewhere in between adding Sprite support, adding Squash support and thinking too much about Draw support and Acorn Latin encodings), but it could be easily expanded with a few days of effort to provide direct online access to GitHub-distributed StrongHelp content (like Steve referred to) via a web browser of your choice.

Should I have a go? I didn’t get any feedback after publishing the StrongHelpViewer source code, but it was of course in unfriendly source-code-only-build-it-yourself-oh-well-you-need-Eclipse-for-that form instead of a proper easy-to-use package. Thinking about it, a service running on a server somewhere and you just need to point the browser to the correct URL would pretty much alleviate that usability problem.