Toolsprites design

I’m having a go at creating some revised toolsprites. I’m a bit stumped about how to make use of the translation tables to allow the input focus to show up.

First query: Am I right in thinking that the Wimp can use toolsprites of any colour depth/palette, but that every sprite in the Tools spritefile has to be the same colour depth/palette? This would explain some odd effects when attempting to use a Tools file containing some sprites with 16M colours and others that have been optimised down to 256-colour or 16-colour palettised. My current theme design is quite minimalist and some of the sprites use less than 16 colours, but I’m assuming that if at least one of them requires a 256-colour palette then they all do, in order to keep things uniform.

Second query: How do I go about creating the translation tables used by the Wimp to tint non-grey toolsprites? I’ve looked at the documents in the source tree and examined the Raspberry theme, but I don’t know how to create the ‘table_x’ sprites with the right coloured pixels in them. If someone knowledgable could give me a brief step-by-step process, that would be really helpful!

but that every sprite in the Tools spritefile has to be the same colour depth/palette?

I have not looked in the source however for the tool sprites, I would imagine the Wimp would build a translation table for “these sprites in this mode” instead of a table for each individual sprite (there are many used in the construction of a window, it could start to get…unwieldly).

castle.RiscOS.Sources.Desktop.Wimp.s.Wimp10, line 424:

;; All gadgets must be defined with the same palette and same mode, mixing is not
;; allowed.  Sprites are allowed to have mode suffix to allow different
;; EX EY factors to be supported.
;;
;; Tools sprite designers can optionally provide a set of precalculated translation
;; tables to map the toolsprites onto the standard 16 Wimp colours. Each table is
;; containerised as a sprite, but really it's just a translation table in disguise.
;;-----------------------------------------------------------------------------

That answers the first question. Must be the same palette and mode.

As for the translation table, we look to castle.RiscOS.Sources.Desktop.Wimp.Doc.ToolTables which pretty much says that 32K/16M tool sprites are not supported:

While 32K and 16M colour tables could in future be supported, their large table size is likely to make them of limited use. Therefore this scheme will use 256 entry tables – note that that’s 256 colours from a 16M colour palette for each of the toolsprite elements that can be coloured

It then breaks down the sprites into four groupings (Title bar and gadgets, Scroll bar inner, Scroll bar outer, Input focus parts) each of which can be a separate 256 colours, allowing up to 1024 colours on-screen in high-colour modes.

The table is constructed as a 256 word sprite (they suggest 16×16 in 16M cols), and is called “table_<wimpcolour>”. A complete set describes the 16 wimp colours.

What I do not quite understand, from this, is how it is possible to use 256-colour icons when you provide translation tables for 16 colours? I guess I ought to examine the Raspberry sprites in more details?
The tables provided for the Pi sprites are table_2 (light grey) and table_12 (cream highlight). It would seem to me that the method is “icon colour → table indice = result”, but I’m not sure how it is possible to associate this colour with that colour. I can only imagine that the Pi tool sprites were not created in !Paint.

Sorry, this part is less helpful. We’d really need some input from the person(s?) that created the Pi sprite set.

castle.RiscOS.Sources.Desktop.Wimp.s.Wimp10, line 424:

;; All gadgets must be defined with the same palette and same mode, mixing is not
;; allowed.  Sprites are allowed to have mode suffix to allow different
;; EX EY factors to be supported.
;;
;; Tools sprite designers can optionally provide a set of precalculated translation
;; tables to map the toolsprites onto the standard 16 Wimp colours. Each table is
;; containerised as a sprite, but really it's just a translation table in disguise.
;;-----------------------------------------------------------------------------

That answers the first question. Must be the same palette and mode.

As for the translation table, we look to castle.RiscOS.Sources.Desktop.Wimp.Doc.ToolTables which pretty much says that 32K/16M tool sprites are not supported:

While 32K and 16M colour tables could in future be supported, their large table size is likely to make them of limited use. Therefore this scheme will use 256 entry tables – note that that’s 256 colours from a 16M colour palette for each of the toolsprite elements that can be coloured

It then breaks down the sprites into four groupings (Title bar and gadgets, Scroll bar inner, Scroll bar outer, Input focus parts) each of which can be a separate 256 colours, allowing up to 1024 colours on-screen in high-colour modes.

The table is constructed as a 256 word sprite (they suggest 16×16 in 16M cols), and is called “table_<wimpcolour>”. A complete set describes the 16 wimp colours.

What I do not quite understand, from this, is how it is possible to use 256-colour icons when you provide translation tables for 16 colours? I guess I ought to examine the Raspberry sprites in more details?
The tables provided for the Pi sprites are table_2 (light grey) and table_12 (cream highlight). It would seem to me that the method is “icon colour → table indice = result”, but I’m not sure how it is possible to associate this colour with that colour. I can only imagine that the Pi tool sprites were not created in !Paint.

Sorry, this part is less helpful. We’d really need some input from the person(s?) that created the Pi sprite set.

Am I right in thinking that the Wimp can use toolsprites of any colour depth/palette, but that every sprite in the Tools spritefile has to be the same colour depth/palette?

Yes, so that they end up with the same translation table, as the Wimp only keeps one based on sampling just one of the lucky sprites – currently ‘blicon’ I think – but that shouldn’t be relied upon and might change.

How do I go about creating the translation tables used by the Wimp to tint non-grey toolsprites? I’ve looked at the documents in the source tree and examined the Raspberry theme, but I don’t know how to create the ‘table_x’ sprites with the right coloured pixels in them. If someone knowledgable could give me a brief step-by-step process, that would be really helpful!

The simplest set to consider is ‘TTTTest’ in the Wimp/TestO directory, just *TOOLSPRITES that and you’ll understand pretty much everything. The Raspberry theme was mechanically generated by loading all the sprites at once and picking the 256 required colours, then applying the reverse operation to the original sprites – remember to keep a backup copy of the originals though!

If you don’t provide the translation table for all colours (the Raspberry ones only provide 2 of 16), or the application author has specified some custom colour by using a ‘C’ validation string, the Wimp will just forcefully tint the sprites in that colour by greyscaling them then using the Ursula tinting algorithm to spray them a different colour.

[Oops, pressed save twice]

Oops, pressed save twice

You can delete postings! But I s’pose that’s only good if the time lapse is suitably small!

Many thanks for the various answers. Think I’ve got it sorted out now. If I do manage to get everything working I’ll try to find time to add to the Wiki on this, as it’s not entirely obvious how to create properly functioning Toolsprites without looking at bits of the sources.

There’s a page here which covers some of the aspects of tool (and icon) sprite design. I’ve recently tweaked it to include information about alpha masked sprites, but I suspect there’s a lot more work which could be done to clean it up (the original version seemed to be trying to lump icon sprites and tool sprites together into the one topic without any real distinction between the two). I’m assuming the original version of the doc was based around something from the PRMs or style guide, but since I’ve only been tweaking it during my lunch hour I haven’t had much chance to go through and review it all properly. So anything you can do to help improve those docs would be great.

There’s a page here which covers some of the aspects of tool (and icon) sprite design.

“although current versions of the Wimp supplied with RISC OS Select will not look for and load alpha-masked sprites automatically”

This is, I presume, some alternate reality where Select receives some more updates to help it run nicely on ancient hardware, right? (^_^)

The Raspberry theme was mechanically generated by loading all the sprites at once and picking the 256 required colours, then applying the reverse operation to the original sprites – remember to keep a backup copy of the originals though!

I’m a bit stuck. I’d like to provide two separate tables for wimp colour 2 and 12, rather than rely on the default forced tinting option. That means that the sprites for the titlebar need to look uniform with the rest when the focus is lost, but tinted yellow (or whatever) when the focus is gained. So they’ll need different colour numbers to the rest of the icons, which all then need to match up to the corresponding values in the translation tables.

With reference to the Raspberry theme, when you say ‘mechanically generated’, do you mean using a tool to automate the process? If so, can it be made available? If not, a step by step description of how to correctly generate suitable tables would be really helpful, as I’m obviously missing something.