“Do nemo it’s Christmas time at all?”

Steffen said

“Compressed” … “RGB packed”

Both originally coined by Computer Concepts, now I check my notes. Though they referred to Type9 as “JPEG” because that’s the only compression scheme they used at the time. The PackedRGB (24b per pixel) was probably abandoned when the RiscPC was released, but I don’t remember when I last saw support for the format in their code… but I have seen packed RGB support somewhere in Artworks, Impression or some CC products. It is simply R,G,B,R,G,B… padded at line ends. (My notes say “Initially supported by Impression and Artworks but later withdrawn, although the code remains” – I don’t know when I wrote that).

Acorn adopted the compressed format in RISC OS 3.5, and every version of RO3, RO4 and RO6 since has support built into SpriteExtend. It also continued to exist in the NCOS branch, but was removed from RO5 before 5.19. Don’t know when.

Acorn’s implementation was very slapdash, and was extended to apply to Sprite Types 4-7 (so any Sprite might be compressed). It’s difficult to overstate just how shoddy Acorn’s detection code was. By simply checking the values that have to be there you can make false-positives fifty-one billion times less likely, and that’s without introducing any additional data (which is what Acorn should have done in RO3.5). I stumbled upon the code in 1994 via such a false-positive with this sprite:

Complete the arrow to make the sprite disappear, due to SpriteExtend mistaking it for a JPEG

So SpriteExtend from 0.61 (1994) through to at LEAST 1.91 (2009) has support for JPEG-compressed Sprites built-in. But SpriteOp is a vectored SWI, so modules are free to support other compression schemes using the same format.

Acorn should have used part of the redundant Left Hand Wastage word to hold a filetype identifying the compression scheme (and they could have reduced Right Hand Wastage to 5 bits at the same time, freeing up 59 bits in the Sprite header!), but they decided to spot the format contextually, and then did so very, very badly indeed. I can see why ROOL removed that implementation [though fixing it would have been fifty-one billion times better].

The format is simply the pixel data holding a length word followed by the data stream, which may have a header appended if it isn’t already easily identifiable. This isn’t a great design, so I’ve also introduced an “Img!” MetaData tag to explicitly define the filetype of the compression scheme. I have a CompressedImage module that formalises compressed sprites, does a certain amount of admin, and issues a Service Call so that other bitstreams can be identified (and also reinstates JPEG support properly for RO5), but the format itself predates RO3.5.

As ROUGOL attendees will know, I’ve demonstrated all kinds of “compressed” Sprites (by which I mean a Sprite containing some other kind of data) including JPEG, PNG, QOI, Draw, Artworks and even CSV!

Here’s an innocuous looking sprite that reveals a surprise:

Never gonna give you SOP

This does mean that one can have vector “sprites” – extremely large ones!

As many pixels as you need

HTH.

But if you believe it does

Tea ejected.
How do I even begin to explain this to my cow-orkers?

This is the ScaleFactor that FontManager maintains.

Ah, thanks for the clarification here. You kept me awake last night trying to work out how to rationalise sprites that can have (arbitrary?) DPI values with a VDU system that has decidedly non-arbitrary eigen values.

Complete the arrow to make the sprite disappear, due to SpriteExtend mistaking it for a JPEG

🤦

but was removed from RO5 before 5.19. Don’t know when.

Bigger question is why. If there’s a documented format that is RGBRGBRGB then it really ought to be retained even if it’s a pain in the arse to read due to not being word aligned.
If one isn’t using a mask, an instant quarter in file size could be saved by using this instead of RGB-and-a-dummy-byte.

my cow-orkers?

Hell is udder people.

If there’s a documented format that is RGBRGBRGB

There was. It was supported by CC software. It has never been supported by RISC OS, IYSWIM. Back in the mid 90s, shaving 25% off your full-colour image was a worthy prize. But these days RO5 users keep telling me that memory is too cheap to count, so it’s a little pointless. In any case, VVS covers that among literally thousands of other shapes.

In an ideal world, SpriteExtend would have revealed the scanline-buffer API that it uses when displaying JPEGs (as it reuses the PlotSpriteScaled code), which would trivially allow any format to be supported with very little code. (And if you’ve ever looked at how much code is involved in calculating which pixels to touch during PlotSpriteScaled and particularly PlotSpriteTransformed you’d realise that it should not have to be replicated just because your pixel format is different).

an instant quarter in file size could be saved

Or you could use a lightly compressed datastream like QOI and:

Day #18: !NZCV

Either you want this or you don’t

CMP can be confusing – it certainly confused Acorn which is why there’s a horrific bug in every version of the Wimp (don’t ever use &80000000 as an iconbar icon priority, or you’ll briefly have two iconbars before the Wimp rubs them together and starts a fire).

Warning: This program shamelessly uses the CMM mnemonic because

1. It’s better
2. My assemblers support it
3. Yours ought to too

The reason it’s better is because the N of CMN and the N of MVN do not mean the same thing, so there are immediate constants that you can MVN but not CMN and vice versa.

Rick realised

how to rationalise sprites that can have (arbitrary?) DPI values with a VDU system that has decidedly non-arbitrary eigen values.

Yeah, but I should also point out that my Wimp scales Template files by the ScaleFactor, which yours does not:

My windows are considerably more 120dpi than yours

At 72dpi the sprites are becoming problematic

Automatically scaling sprites is on my list (after all I have automatic gamma correction already), but the confusion I mentioned earlier persists: “90dpi” probably meaning EigenFactor=1 and hence a division of the ScaleFactor-implied resolution, wherease “300dpi” definitely means 300dpi regardless.

Acorn did us few favours with the RO3.5 SpriteType.

But if you believe it does, you probably voted for Brexit

No, because I have more than one operational braincell. Although the belief bit does start you down the George (Bishop) Berkley track.
Unfortunately, this leaves me permanently astounded how many people were incredibly¹, incredibly stupid and did vote for Brexit.

¹ actually, that’s not true, I have done IT support for a number of decades, so I’ve seen so much Genuine Stupidity, even the Artificial Stupidity (known as AI) fails to surprise me.

I can assure you Steve that the you in your quote is not you, but one.

Cos we all know one.

I should also point out that my Wimp scales Template files by the ScaleFactor, which yours does not

Ah, which means we don’t have to worry much about “doing the right thing” as our Wimp is too braindead to do anything like that level of fanciness.

but the confusion I mentioned earlier persists: “90dpi” probably meaning EigenFactor=1

It’s not confusion if you look at the VDU source. This is in vdrudriver (well, ours, you probably fixed yours):

        TEQ     r1, #180                        ; 180 => xeig=0
        MOVEQ   r1, #0
        BEQ     %FT20

        TEQ     r1, #22                         ; 22/23 => xeig=3
        TEQNE   r1, #23
        MOVEQ   r1, #3
        BEQ     %FT20

        TEQ     r1, #(45 :SHL: 2), 2            ; check if 45   (EQ,CC if so)
        CMPNE   r1, #90                         ; or 90         (EQ,CS if so)
        BNE     %FT85
        MOVCC   r1, #2                          ; 45 => xeig=2
        MOVCS   r1, #1                          ; 90 => xeig=1

Repeat again for yeig.

Elsewhere, NewSpriteModeWord (in vduswis) remarks:

;        4 XEigFactor         returns 0,1,2 for 180,90,45 dpi, error otherwise
;        5 YEigFactor         as XEigFactor

wherease “300dpi” definitely means 300dpi regardless.

Hmm, from the documentation:

Note that many OS APIs will only accept a sprite mode word if the horizontal and vertical DPI fields contain DPI values that can be expressed as eigen values; i.e. 180 DPI (eigen value 0), 90 DPI (eigen value 1), 45 DPI (eigen value 2) or 22 or 23 DPI (eigen value 3).

Which makes me wonder how well regular non-nemo versions of the OS would cope with things like 300dpi images?
It isn’t necessarily an invalid question either, given that even cheap’n’cheerful printers can handle scanning at various (200, 300, 600, etc) DPI and one might prefer to see a scanned image in a better quality and not simply bigger (leaving you and/or the application to change the plotting size accordingly, which is non-trivial as the standard sprite scaling provided by the OS is horrible beyond description, being written for speed rather than accuracy).

[Brexit stuff moved here]

So far this has been a great topic about Nemo’s xmas programming marathon, please don’t pollute it with political ranting of any flavour.

how well regular non-nemo versions of the OS would cope with things like 300dpi images

You can always be relied upon to ask the right question.

By which I mean the question with the horrific answer.

Vantage scales the sprite according to its DPI (and there’s a “DPI” MetaData chunk that specifies 16.16 dpi so that original formats that specified resolution in lpcm can be accommodated – lines per cm). ISTR that Impression scaled too.

The SpriteOps however are exactly what you’d expect a random selection of RO developers to come up with (mostly out of spite):

…complicated…

The usual rule applies: RO5 is actually RO3. RO4 has been further developed, which means more features but also more bugs. Note that RO4/6 recognise eigenfactor 4, which can’t be represented at all in RO5’s “Extended” Sprite Type. And RO4’s support for rectangular pixel resolutions is “complex” but significantly more ambitious than RO5’s RO3-era match-or-ignore. (What the bunch’o’nums means is that rectangular pixels where Xdpi is ~twice Ydpi sometimes come out rectangular and sometimes square because of reasons)

Programs such as PhotoDesk, ImageMaster/DPlngScan and ISTR Irlam’s scanning software would usually record the actual DPI of scanned images. So “300dpi” and “600dpi” should be believed… though the OS never recognised them, apps did. But as I say, if by the same mechanism a Sprite is labelled “90dpi” or “180dpi” then it shouldn’t be believed – as that’s most likely to be a pixel-relative measurement, i.e. notional.

NOTE IN PARTICULAR that because the stupid SpriteType DPI fields were integer, they could not accurately record MODE 2, which is 22½dpi, not 22 or 23. This causes some code to get MODE2 sprites the wrong size, which is sacrilege.

Just to make life even more complicated, I often produced artwork with 150dpi photos if they were to be printed with a coarse screen on newsprint, because further detail would be lost in the screening. So “150dpi” would be real, but 90 and 180 are notional. 45 is notional, but 22 and 23 mean “notionally 22½”. (And if you ever implemented the “MODE8” from the Beeb’s AUG you’ve used an 11¼dpi Acorn bitimage, so there)

IFRv2’s sprite rendering takes all of that into account. In practice you’re never going to see a 47dpi sprite, so whether you treat that as notional (ScaleFactor influenced) or absolute is probably risk-free [though not rick-free as I originally typed].

Hey, what happened nemo? Did you run into a bug in the OS that made you think “aw hell no!” and decided on a whim to fly off to a remote desert island to recover?

Anyway, happy holidays whatever one(s) you celebrate and best wishes for 2025.

PS: What StrongHelp file is that?

To answer your question, as usual I got tired of the culture of this place and returned to a site that has a block function.

The rest of December’s releases have been:

Day #19: !Modules
Day #20: *Vectors
Day #21: UnReadC
Day #22: *DAs
Day #23: VDUMode
Day #24: !ToolMenus

PS: What StrongHelp file is that?

My own, which I’ve been augmenting for decades.

Anyway

A very Merry Christmas to you and all those who have been constructive contributors to the RISC OS world this year. And bah humbug to the rest.

The world is what you make of it

To expand upon that for those who ought to be interested:

Day #19: !Modules

App to list modules (various sort orders), manage them, etc. Has the ability to craft a ServiceCall with R0-R8 (and various fields pre-defined) which can be directed to a specific module.

Day #20: *Vectors

This does the same as the *Vectors command in DebugTools, but in a more compact form. Pick your preferred:

DebugTools:

Software vector WrchV (&03)
  Code  - Address &FC34DE44 is at offset &0000149C in module TaskWindow
  Wkspc - &2005C854
  Code  - Address &FC045B44 is at offset &0002553C in module UtilityModule
  Wkspc - &FFFF09A0
Software vector RdchV (&04)
  Code  - Address &FC34E178 is at offset &000017D0 in module TaskWindow
  Wkspc - &2005C854
  Code  - Address &FC046720 is at offset &00026118 in module UtilityModule
  Wkspc - &00000000

Or nemo’s succinct utility:

&3:Wrch
         2005C854 FC34DE44  TaskWindow+149C
         FFFF09A0 FC045B44  UtilityModule+2553C
         
&4:Rdch
         2005C854 FC34E178  TaskWindow+17D0
                0 FC046720  UtilityModule+26118

Note: If you have DebugTools loaded, you can’t *Vectors as that’ll call the module command by preference. Instead, you can *Run Vectors to run this version instead of the one in the module, or enter *Alias Vectors Run Vectors to hijack the command to do the right thing. If you’re worried about paths, you’re “holding it wrong”. Bung it into $.!Boot.Library and it’ll automagically just work.

Day #21: UnReadC

Does what OS_ReadC does, only backwards. ;)

Day #22: *DAs

Now you would have thought that DebugTools, with the ability to *SaveDA and *RemoveDA might have had a way to show the DAs? Evidently not…
Up steps nemo with a tool to show them all of the necessary things listed, and of course there are options too.

Day #23: VDUMode

Use VDU sequences to select modes. Interesting commentary in the help file regarding “dogfooding”. That’ll be another of Gerph’s comments about collusion, no doubt.

Day #24: !ToolMenus

Now this one is interesting. When run, clicking Menu on some part of the window furniture will pop up an appropriate menu with various related options. And since it’s a nemo menu, it has little monochrome icons on the left to make us wish that all of the menus had visual cues like that.
[yes, I know there’s a module to do that, but it’s not a standard part of the OS’ menu handling]

My own, which I’ve been augmenting for decades.

Any chance you’d consider sharing it?

As this is day 24, thus the end of the calendar, all that remains to be said is……

Thank you nemo for these creations, and a Merry Christmas to you too.

Over at the social stuff, nemo wrote:

It’s surprisingly disruptive and has meant I’ve got nothing significant done for a month. Serves me right.

I did “a blog article a day” in December in 2014-2016, even if it was just linking to the YouTube video. But it was a pain in the arse.

So when I did it again in 2021 ¹, I cheated. As I wrote my normal blog stuff in the autumn, I would always write an extra fragment and store them in a directory. So maybe a third of the month’s content was “fresh”, the rest had already been written by mid November.
I know my mind, and I know my concentra…oh, shiny…so I knew that it would be hell having to write stuff for an entire month.

No, I have no plans to repeat the experience, even planning it all out ahead of time.

¹ I failed by one day. I had a double dose of Covid and flu vaccinations (one in each arm) and this stupid corpse that I inhabit really wasn’t okay with that the next day…