MultiTask version 7.30

In response to a request from Jim for a utility that will examine sprite files held within a Draw file, version 7.30 of !MultiTask [Edit: updated to 7.31 to fix a bug] will now include a sprite info file listing each sprite found within a draw file.

The request was:

I’m in the midst of a tiresome time-consuming hassle, that certain sprites in a document go missing when the document is made into PDF.

Does there exist a utility that will examine a batch of sprites and give me a list reporting their format, colour depth, existence of mask or palette (etc)? Or, even better, to find and report on sprites contained within drawfiles or Artworks files (etc)?

There does now. For an Artworks file first export as Draw and then proceed as below.

!MultiTask version 7.30 is available from my web site and will generate a list of sprites contained within a draw file along with any warnings of new sprites with non-zero left hand wastage (** Illegal NZLHW) and 1bpp 2bpp 4bpp ‘new format’ sprites (** deprecated) when asked to regenerate a draw file. This is done by running the application, clicking on its icon bar icon and dragging a draw file into the windwo that it opens. Now move right over the menu option ‘Regenerate’ (with a read/write version of !SparkFS running) and save a zip file – this will contain a BASIC programme to regenerate the original Draw file, plus any embedded Sprite and JPEG files along with a ‘SprInfo’ file like this:

SprInfo:
1: Old format Mode 21 640 × 512, 256bpp has mask – sprite name: file_ff9
2: New format 8bpp palletised ** deprecated has mask – sprite name: file_feb
3: New format 8bpp palletised ** deprecated has mask – sprite name: file_ffb
4: Old format ** Deprecated Mode 28 640 × 480, 256bpp has mask – sprite name: file_ff9
5: New format 8bpp palletised ** deprecated has mask – sprite name: file_ff9
6: New format 8bpp palletised ** deprecated has mask – sprite name: file_ff9
7: New format 8bpp palletised ** deprecated has mask – sprite name: file_fff
8: New format 8bpp palletised ** deprecated has mask – sprite name: file_ff9
9: New format 8bpp palletised ** deprecated has mask – sprite name: file_fec
here sprite 1 is RO 3.1 compatible
and sprite 4 is a deprecated mode number (see PRM 1-751)
and the rest are deprecated new format 8bpp sprites

The problem Jim was seeing can be explained as follows:

If you import a ‘new format’ (RISC OS 3.5 or later) sprite into ArtWorks, the sprites will appear invisible if they are 1bpp, 2bpp or 4bpp. The common convention is to use the “new” format (RISC OS 3.5) for 32k and 16M sprites only and continue to use the RISC OS 3.1 format for 256 colours and below. Using ‘new format’ 1bpp, 2bpp and 4bpp sprites is deprecated in a rather obscure way in PRM 1-751).

As there are very few “new” format sprites with 256 colours and below around, ArtWorks still only supports the “old” format for 256 colours and below. Unfortunately RISC OS 5 uses them extensively – all the icons used by the filer for ‘file_xxx’ are ‘new’.

Using !DPlngScan 1.18, if you import a new format 256 colour sprite, with mask, with Choices/Sprites/Old sprite format ticked and then save it, the mask is preserved and an old format sprite generated which will appear correctly in ArtWorks and in PDFs.

The other issue is that with OS versions prior to Sep 18th 2014, the *screensave command (with a graphics viewport defined) sometimes produced new format sprites (C32k for example) containing lefthand wastage which then cause (different) mayhem with !Paint, Artworks, PhotoDesk etc. I demonstrated this on an Iyonix with RISC OS 5.16 and 5.20. A simple workaround was to use C16M sprites which cannot have left hand wastage.

Hope this helps

Edit: Now at version 7.32 and includes an example of a draw file containing illegal sprites: the file is examined and disassembled, the original draw file is recreated identically by running the generate programme. The sprites can then be loaded one by one into !DplgScan and re-saved with the option save as old type sprites and you know that the new draw file will be identical to the old but with legal sprites.

Now updated to version 7.35 to indicate RGB sprites (such as would be saved by the *ScreenSave command on the Titanium) as opposed to VIDC-compatible BGR sprites (the only type recognised by RISC OS prior to 2013) – example below of the result of decoding a Draw file containing a 16-colour, 32k colour and 16M colour sprite created by screensaving on Titanium:

  1: New format 4bpp palletised ** deprecated no mask - sprite name: screen
  2: New format 16bpp 1:5:5:5 TRGB (non-VIDC) no mask - sprite name: screen
  3: New format 32bpp 8:8:8:8 TRGB (non-VIDC) no mask - sprite name: screen

Updated to version 7.40 (11-Feb-2016) which now has its ‘Help’ in a StrongHelp file (rather than a text file) and offers an option, when examining a Draw file, to output a version of the same file with its bottom left corner reset to (0,0) but otherwise identical.

Now updated to version 7.50 to add a simple facility to date stamp a file with a specific date and time.

I know your original posts are from 2015 but I’ve been struggling to understand what you meant by “deprecated”, so I downloaded your zip. Tangential point: had some problems extracting SprInf/zip but maybe that’s a local problem.

Your !MultiTask.!RunImage code correctly describes new sprites with non-zero left wastage as “Illegal”, I’m with you there. But you describe most ‘old’ sprites (MODE numbers) and all ‘new’ sprites with eight or less bits per pixel as “deprecated”.

By what authority?

Apart from a whitelist of sixteen mode numbers, you declare all other mode numbers as unacceptable, yet the documentation here unambiguously defines 54 modes – which you seemed to have transcribed into the program anyway. RISC OS 5 certainly understands all 54 of those modes, and even RISC OS 4 from 15 years ago knows all but the last four. Since RISC OS is unlikely to be so short of bytes it has to shed this tiny amount of information from the Kernel, in what way are these mode numbers “deprecated”?

You then go on to also describe sprites with ‘mode words’ specifying 1bpp-8bpp as “deprecated”, presumably because your minimal whitelist includes modes with each of those colour depths that you believe should be substituted. But mode words specify more than colour depth, they also encode resolution. How else, pray tell, is one to encode a monochrome 600dpi scan other than by a mode word of &89604B1? How else can one construct a 256 grey image with an alpha mask but &A01680B5?

I can find no mention in the documentation here of deprecated modes or mode words. So, what’s going on?

The PRM 1-751 suggests only mode 0,4,18,8,1,19,12,9,20,21,13 and 15 for old sprites (the other mode numbers just indicate a bigger or smaller monitor at the same colour depth and bit density) and PRM 5a-110 that palletised new format sprites are not supported. A 600dpi monochrome sprite (a bit exotic) cannot be described by an old sprite so has to be a new sprite.

I don’t think my disassembly of a draw file containing sprites is intended to give exact details of every variant.

PRM 1-751 suggests only mode 0,4,18,8,1,19,12,9,20,21,13 and 15 for old sprites

This is not the same as “deprecated” which implies that a feature, design, or practice will be removed or discontinued entirely in the future – those numbers may well be “recommended”, but that does not mean others are “deprecated”. Indeed, I think the text reads:

To make your sprites readable by old releases of RISC OS, we
recommend you use the following mode numbers in a sprite

which is a long way from deprecation.

and PRM 5a-110 that palletised new format sprites are not supported

Again, you’re misrepresenting what the text says:

1     1bpp image; 1bpp mask; palette not supported by RISC OS 3.5
2     2bpp image; 1bpp mask; palette not supported by RISC OS 3.5
3     4bpp image; 1bpp mask; palette not supported by RISC OS 3.5
4     8bpp image; 1bpp mask; palette not supported by RISC OS 3.5

Just because something is not supported on RO3.5 does not mean it is deprecated thereafter (and TBH I’m not sure what this is claiming, because plenty of RO3.5 software did support such sprites – I’ll try and work it out).

I don’t think my disassembly of a draw file containing sprites is intended to give exact details of every variant.

I don’t think you went to all that detailed trouble just to mislead people.

For the avoidance of doubt, “deprecated” should be taken to mean “likely to stop working in the next version”. It is not the word to use for “not as portable as some other alternative”.

Perhaps appropriate sentences with the word “legacy” should be used?

Wording to the effect that OS revisions lower than 3.5 support only legacy numbered modes so for compatibility with those revision you should use…

The word “deprecated” in the table Chris gave could be replaced by “unsupported in legacy mode OS (RO <3.5)”

That seem the best route?

Perhaps the first route is to determine what the OS actually supports. We all have enough stories that while the published API describes the API, it doesn’t necessarily describe reality.
Are the not supported sprite formats really not supported? Not supported on certain hardware? Etc.

Why would a paletted 16 bit colour image not be supported anyway? It’s things like that which permit one to view teletext screens (and the like) – use a 16 colour mode, set the colours to the same as the BBC Micro, draw into it. Well, it’s either that or waste memory with higher colour depths than necessary due to strange OS limitations…?

Why would a paletted 16 bit colour image not be supported anyway?

Because, under RISC OS, a palette with 65536 entries is unheard of?

Probably you meant 16 colours instead of 16 bit colour?

Because, under RISC OS, a palette with 65536 entries is unheard of?

I often have to remind people that “I do not know about” is not the same as “does not exist”.

32K sprites with a palette do not have 65536 entries, obviously. I have supported paletted deep mode sprites since 1994, and indeed they’re essential in some workflows. SpriteOp 40 vindictively refuses to return sprite information for such sprites (despite the information it returns not having anything to do with palette content) but if you’re not relying on that SpriteOp to understand the ‘new’ sprite mode word (and the whole point of the format is to be self-documenting) then SpriteOp is perfectly happy to plot such a sprite.

ColourTrans is currently no help for producing translation tables in one call, but you can construct one manually and colour mapping functions certainly can use the palette directly (which is my preferred method). The formats I support are:

So for the RGB formats, you can have either a single shared palette entry per component level (which acts as three independent transfer curves), or three full colour palettes (which must be combined in the usual way). I’ve not implemented transfer curves for CMYK as palette entries are definitely RGB, so only expect four colour palettes.

As always, the secondary palette tends to be used for non-visible functions such as contone detection and level storage, and other app-specific uses. I’ve not built such a sprite with flashing colours, but I do support flashing colours generally, so it might already work!

eg

BTW my multi-planar sprite format supports up to 255 components and absolutely requires a palette, so the palette data can be quite large if you have say eight components per pixel (which I have used).

“Whaddya mean, flashing palettes?”

This brings to mindd a ‘Yes Minister’ sketch where Hunphrey advises the Minister to criticise the conclusions of a report by saying that the conclusions have been questioned. The Minister says ‘but what if they have not been questioned?’ Humphries’ answer is instructive – ‘then question them Minister, then they have.’

As Artworks baulks at the sprites I mention, that is my reason for saying they are deprecated: a major RISC OS application cannot handle them so this is not some hypothetical future…

Then you’ve misunderstood the difference between deprecated (used to work, may not in the future) with unsupported by a specific program.

Artworks does not support all the winding rules that Draw does. That does not mean those winding rules have been deprecated. RISC OS 5 does not currently display CMYK sprites. This does not mean that CMYK sprites are deprecated.

The word you’re looking for is not “deprecated”.

My dictionary says the meaning is ‘to express disapproval of, to protest against’. That is exactly what I am doing. But (mustn’t start a sentence with a preposition) I am enjoying the new information that is emerging from this vigorous debate. Once ArtWorks supports them perhaps I’ll find a different word. Non-preferred. Brave. Hopeful. Optimistic.

My dictionary says the meaning is ‘to express disapproval of, to protest against’.

Your dictionary might do, but “deprecate” has a very specific meaning in the technical context that you’re using it in, and it’s not the one in the OED.

https://www.merriam-webster.com/words-at-play/deprecate

Humpty Dumpty used to say when I use a word, it means what I want it to mean. It is a question of who is master. Besides some software now does not support it. It is unlikely to change so even the technical meaning is right.

Besides some software now does not support it. It is unlikely to change so even the technical meaning is right.

On that basis, every new feature added to RISC OS is deprecated as soon as it is complete… The key point about deprecation is the intention to remove the feature in the future.

That comes associated with an expectation that new features will be implemented. If that is not the case then, indeed, any new features will de facto immediately be deprecated.

As nemo (and others) quite correctly state – ‘deprecated’ has a very specific meaning in technology circles: “This is no longer maintained, nor the preferred way of doing this. We will throw warnings at you every time you use it and it may in fact be completely dropped from the codebase with no futher notice. You have been warned – do not use. And in fact, consider this a tech-debt that needs fixing”

From the description, what you are looking for is “Legacy” or “Unsupported by APPLICATION_X”. But definitely not “deprecated” – it’s an erroneous and confusing term to apply in this situation.

‘to express disapproval of, to protest against’

Yes, as in self deprecating humour.

However, words with a specific technical meaning can mean things that are different to the everyday interpretation.

Consider “allergic”, “sociopath”, “benign”, “deflection”, “baud”…

Probably you meant 16 colours instead of 16 bit colour?

Uh… Hangs head in shame. Yeah. That’s what I meant.

Besides some software now does not support it.

Some software doesn’t support the clipboard protocol. Some software makes a mess of RAM transfer, or doesn’t even bother and just bounces data via Wimp$Scrap.
That doesn’t mean either are deprecated, it just means some software “don’t do it right” (or at all).

That comes associated with an expectation that new features will be implemented.

In this post referendum agile waterfall devops world, I wouldn’t consider that there is any correlation between a new feature being mentioned (even if “promised” in giant lettering on the side of a bus), and it actually existing in reality. :-)

I think it is a pity that the bus seems to have disappeared.

As nemo (and others) quite correctly state – ‘deprecated’ has a very specific meaning

And especially so in the Announcements forum of the ROOL website.

Chris, we’ve tried advising you but you seem to think this is a matter of opinion. It isn’t. Please feel free to express your opinion about the future shape of the RISC OS API in any of the many forums available (General, Code review, Bugs even) but announcing your judgement (or a program that expresses your judgement) in this one as if it is a fact lends it an element of officialdom it does not merit.

These sprite types are not deprecated, they may be unusual, unhelpful or even ill-advised, but they are definitely not deprecated.

Humpty Dumpty used to say when I use a word, it means what I want it to mean. It is a question of who is master.

To which the answer is “no one round here”

From the description, what you are looking for is “Legacy” or “Unsupported by APPLICATION_X”

That takes me back 6 hours…

Yes, as in self deprecating humour.

Que? No understand. Not something I’ve ever done. :) On which note: End.

These sprite types are not deprecated, they may be unusual, unhelpful or even ill-advised, but they are definitely not deprecated.

I shall replace ‘deprecated’ with ‘ill-advised’ and update the application accordingly. Done.