Proposed GraphicsV enhancements

Ah, well spotted.

FWIW we’re currently using 50% opacity by default, 60% opacity in 256 colour modes (which I found helped the icons to keep their colour better), and the old hatching method in 2 colour modes. And disabling the drop shadow if hatching requested and DragASprite reckons translucency is supported (i.e. recent SpriteExtend + more than 2 colour mode)

“Full support at the OS level is pretty much there – download the latest ROM and give it a go.”

That’s excellent news; thanks for letting me know. I apologise for not knowing already, but I’m afraid I don’t keep tabs on the RISC OS world in the way that I once did.

Absence of support for alpha-masks in Paint would still present me with problems, I’m afraid, as I need to use Paint for certain aspects of the icon creation (notably the tall-pixel versions); but perhaps it’ll be possible to work around the current limitations. I’ll have to see.

I’m currently awaiting a final ‘bit’ (HDMI adaptor) before I can use my new Raspberry Pi, but once I’ve got it, I’ll investigate what’s possible on that. I’ll need to find a significant stretch of time to produce a new alpha-transparency icon set, but if it’s now feasible then it’s going to be a matter of ‘when’ rather than ‘if’.

Richard, you may like to look in on the Paint bounty proposal thread.

For *IconSprites, the OS currently looks for sprites in the following order:

1. !Sprites23 (if 90 DPI 1bpp mode – old Arc rule to cope with mode 23)
2. !SpritesXY (where X and Y are appropriate for the DPI – 1 for 180 DPI, 2 for 90 DPI, 4 for 45 DPI)
3. !SpritesXX or !SpritesYY (if rectangular pixel mode. It favours lower DPI values, so !Sprites12 will be changed to !Sprites22)
4. !Sprites22 (if XY were 11)
5. !Sprites

There are two important things to realise here:

1. The different combinations are always applied as suffixes to the original filename
2. The standard sprite filename, “!Sprites”, is 8 characters long

With the above in mind, I’m proposing adding the ‘A’ flag just before the XY specifier. This avoids breaking with the tradition of all variants being suffixes, and avoids ambiguity on systems with 10 character filename limits (specifically, it guarantees that when the filename is truncated it won’t overwrite a non-alpha sprite and cause problems from the old OS version unwittingly trying to load it). With DPI being given priority over alpha, the new list would be:

1. !Sprites23
2. !SpritesAXY
3. !SpritesXY
4. !SpritesAXX or !SpritesAYY
5. !SpritesXX or !SpritesYY
6. !SpritesA22
7. !Sprites22
8. !SpritesA
9. !Sprites

Note that there’s no !SpritesA23 as using an alpha sprite in a 1bpp mode is a bit pointless.

Anyone have any objections to these changes?

The standard sprite filename, “!Sprites”, is 8 characters long
With the above in mind, I’m proposing adding the ‘A’ flag just before the XY specifier

Given X and Y are currently restricted to 1/2/3/4, you could use 5/6/7/8 to signify the alpha equivalent (ie. any bit 2 set), which then keeps all combinations within the 10 letter name limit.
A little like MODE &80 being the shadow mode equivalent of MODE &00.

Sprow: Would it be wise to restrict expansion of the DPI settings when a lot of smaller screens at the moment are far exceeding those DPI settings? Imagine running RISC OS on an iPad screen for example.

If we want to keep the suffixes at two characters, I’d prefer changing it so that there’s only one character used for specifying DPI instead of two. This would mean there’s no way of creating alpha sprites specifically for rectangular pixel modes, but since almost everyone works with displays with square pixels these days I don’t think that’s going to be an issue. So in a 90 DPI mode the OS would look for !SpritesA2, !Sprites22, !SpritesA and !Sprites.

So in a 90 DPI mode the OS would look for !SpritesA2, !Sprites22, !SpritesA and !Sprites.

I was just starting to write a proposal identical to that, so instead I’ll say +1.

+=1

A related question: What do we want the ‘A’ flag to mean? Just that alpha masked sprites are supported, or that both alpha masks and the new RISC OS 5 sprite types are supported? The discrepancy between the two isn’t that relevant for RISC OS 5, but would be important for if support for the ‘A’ flag was patched into RISC OS Select.

The only good reason I can think of for allowing RISC OS 5 sprite types to be used in icons would be to allow some memory to be saved if you want a sprite with 16M colours and alpha – in which case a RISC OS 5 alpha channel would save a fair bit of memory compared to a RISC OS Select alpha mask.

Is there any reason not to keep suffix meanings as they are, and just replace ‘!’ with ‘A’ for the alpha versions.

A related question: What do we want the ‘A’ flag to mean? Just that alpha masked sprites are supported, or that both alpha masks and the new RISC OS 5 sprite types are supported?

I’d go for support for both 8bit mask and alpha channel types.

Is there any reason not to keep suffix meanings as they are, and just replace ‘!’ with ‘A’ for the alpha versions.

*IconSprites Foo

There’s no requirement for a sprites file to be called !Sprites.

There’s no requirement for a sprites file to be called !Sprites

Indeed – there are already apps that use 4Sprites and 5Sprites variant files depending on which version of OS the app is running on.

Maybe overkill, but as I understand it we have the following limitations of the current !Sprites system:

1) The container format must be a spritefile. Any unknown sprite formats crash and burn Filer.
2) The DPI setting must be defined.
3) The BPP setting must be defined.
4) Alpha/mask options must (now) be defined.
5) The Spritefile container format is extremely limited in scope.
6) Images must be sprites.
7) The colour model must be RGB (ie. what if the display needs to be BGR, or CMYK).

We know that display requirements are changing rapidly – and as a result a comprehensive developer must support a variety of formats. I can easily see a need for 300dpi square-pixel images (for ‘retina’ screens); but equally we might wish to create a resizable Filer and Iconbar in future where different sized icons are necessary. The same restrictions of bitmaps is also a problem in the Wimp environment.

So – what about using a different container to the Sprite file?

Have two files: !Iconset and !Icons.

!Iconset is a container file of icons to be used by the system.
!Icons is a container of source vector images.

The container file would by default be a DrawFile – but you can imagine ‘other container files are available’. The nature of this container should be abstracted away – the Filer should not care what the container is. I’m anticipating a ‘ResolutionIndependentBitmaps’ module to handle this (RIBS?)

Within the draw file, I believe there is a ‘tagged group’ object to allow you to provide a group of objects with an arbitrary name (and if not, it’s pretty easy to visualise one). Include a series of images within a tagged group; set the group’s tag as the image name. The objects within that group are different representations of the same image. Enumerate the objects and query them for their size/dpi/alpha/colour model/add any other parameters that may come along later. If a suitable image is found – use that and add it to our sprite pool and dump the file once all ‘tagged group’ objects have been checked. If no suitable image is found, we use the !Icons file (which contains an image held inside a ‘tagged group’ object. That image would preferably be vector (but could be bitmap – anything that is renderable in Draw). We convert that image to the required size/dpi/transparency required and add it to the !Iconset file so that we only have to convert once.

The principle advantages:
- Resolution / colour / size / alpha independence.
- Further future expansion possible using an extendible format.
- If implemented in a separate module, potentially this could be used outside the Filer in wimp applications that need bitmap images (eg. Toolbars, themes, tool sprites etc etc).
- Files can be inspected in Draw (and if we implemented tagged group names could also be created and set up in Draw).
- We’re not restricted to sprites as our bitmap or indeed Draw as our vector. Extension of the Drawfile format or development of image conversion tools would permit changing from one form to another. This may be relevant as the nicest icons might make extensive use of blends or other vector techniques that Draw currently doesn’t support well. Clearly Draw would also need transparency support to implement alpha.
- Developers need only develop a single image if they wish.
- Application directory names > 12 character are solved at the file end (but obviously not at the OS end if the resulting files are going to be dropped into a sprite pool!)

The principle disadvantages:
- Additional code complexity
- Load size. I suspect this isn’t too bad as most sprite files are a few K at best; we’d need to think about big files such as the Wimp sprite pool as scalability may be an issue.
- Speed. Mostly tied to load size, but clearly some would be in the speed of the conversion of vector to bitmap.
- What to do if we need to create the file from the source vector but the filesystem is read only?

Additional requirements:
- Draw to support ‘tagged group’ objects with a group name.
- DrawFile to support transparency for alpha blending.
- Further Draw rendering options to improve the quality of the images that can be provided.

(NB a few edits made just to tidy up descriptions/thoughts).

On returning home, I’ve checked: tagged groups in a Drawfile don’t exist – they are just ‘group objects’ (standard object type 6). The group name is clearly a very old but little / unused feature and isn’t part of the !Draw UI.

Proposal would therefore have to include changes to the Draw application UI to support group names. The select menu could have an option ‘name’ which allows you to enter the name for a group.

A more complex but neater solution would be a widget on the bottom border of the group’s red dashed box. When a group is selected, the name could appear below the group in a red box below the group name. An unnamed group has an unobtrusive placeholder of some sort to allow you to enter a group name (? red box centrally on the lower border?). A named group has editable text. The group name is only visible when the object is selected.

NB Object type 6 as it stands has a character length of…12 characters. An alternative is a new object type number so we have a +0 flags word, +4 pointer to name and +8 pointer to data block. That gives us unlimited name length and expansion as needed. Obviously at the cost of only rendering named groups on RO5 – a 12 letter character name will render on everything without breakage.

The group name is clearly a very old but little / unused feature and isn’t part of the !Draw UI.

!Draw isn’t the only piece of software to make use of DrawFiles. :-)

I know !DrawPlus has named objects, but I’m not sure how exactly they are implemented, if within the constraints of the existing system, or as new objects? I’m pretty sure the layers and locking attributed are new objects.

Ideally, !Draw needs to be a little more like !DrawPlus…but that’s a discussion for a different topic…

Rick: Indeed so on the Bounties forum I thought I’d do exactly that. Even if just as a scratchpad for ideas. Feel free to add to it. I’ve tried to stick to !Draw (as opposed to Draw, Drawfile modules) stuff – but there will inevitably be crossover.

Those are some interesting ideas William, and something we might possibly move to in the future, but they’re a bit beyond the scope of what I’ve currently got planned :)

7) The colour model must be RGB (ie. what if the display needs to be BGR, or CMYK).

SpriteExtend is capable of converting between different colour models when rendering sprites. So it’s probably best to stick with the most backwards-compatible sprite modes where possible and let the OS deal with the rest – i.e. use a 256 colour sprite with no palette for most cases to ensure Arc compatibility, and then either use a custom 256 colour palette or a RISC OS 3.5 15bpp/32bpp sprite if you need more fidelity. And then add an alpha mask if you really need it.

While looking at sprite stuff recently I have realised that the Wimp does try pretty hard to hide its sprite pools from programs so that they can’t directly tamper with them. So if performance of sprite rendering becomes an issue I think there is scope for the Wimp converting icon and tool sprites to more optimal formats, either when loading them or on mode changes. This would ideally be integrated with graphics acceleration, so that the sprites could be converted to a GPU-friendly format and rendered in a hardware accelerated manner where possible.

Jeffrey: Wasn’t proposing it should be implemented immediately – just that it makes more sense to propose a roadmap than to expand what I think is already an overburdened scheme which still has limitations (the !Sprites naming system): and I think you might still run into trouble by extending the Sprites naming system further.

The proposal was ‘road mapped’ in the sense that a minimal implementation would be implementing !Iconset and enabling group names in !Draw: after that it’s no harder to make a pre-formed icon set as a developer (with usual fallbacks applying). Later on, conversion from a source file could be added.

Abstract out choice of image to a module, and have a SWI call:

SWI ModuleName_BitmapsFromIconset

Entry:
R0 = 0 to use current mode, or pointer to mode definition block.
R1 = Pointer to filename.
R2 = Destination sprite area (do we also need an R2 = -1 to check size)?
R3 = Maximum size of sprite area

Exit:
If R2 = check size, R3 would have to return size of sprites required.
R2 updated with desired sprites.

Also: why not hold off the !Sprites extension for now? You could trial out the images with the Wimp sprite pool / Themes (as you know that they’ll be loaded on a 5.21 system); then consider options later when you’ve proven adequate filer handling and rendering with ROM-held resources.

Sprite pools in the longer term should be read-only except via specified interfaces or in explicit circumstances (eg. inside !Paint or where output is being made directly to a sprite): I suspect that is mostly (but not entirely) true for the Wimp pool which is where this needs to be true the most. It would be helpful to ensure it is entirely true and eliminate any write accesses to the Wimp pool. That gives you maximal flexibility on how to play the video abstraction. It may sometimes be better to have the graphics driver ‘in control of the image pool’ rather than the Wimp or the application. On a shared memory system it’s irrelevant but where there is separate video RAM you would want the option of a series of driver-controlled VRAM-held image pools on those devices rather than DRAM-held. Providing applications play nice and use OS calls to access the pools, there are options there. I’ve avoided the use of the word ‘sprite’ because the pool data may not necessarily be held as a sprite – it could be on a bitmap format internal to the graphics hardware, or indeed it might be that raw vectors are passed to the hardware.

Would it be wise to restrict expansion of the DPI settings when a lot of smaller screens at the moment are far exceeding those DPI settings? Imagine running RISC OS on an iPad screen for example.

The 1/2/4 corresponds to eigenfactors of 0/1/2. I’ve scribbled on a bit of paper but I’m struggling to think what eigenfactors of -1 downwards means: 1 OS unit takes half a screen pixel? Supporting 360 or 720 dpi would probably mean re-baselining what the default DPI is and extending up in the other direction.

My main desire was to keep whatever scheme fitting into 10 letters unambiguously since the Wimp still works fine on pre RISC OS 4 machines. I suspect alpha sprites wouldn’t get very far on a kernel of that vintage though, so the Wimp might well skip alpha sprite tests on those targets (just as it skips Sprites11 checks on kernels that don’t render 180dpi right).

If we want to keep the suffixes at two characters, I’d prefer changing it so that there’s only one character used for specifying DPI instead of two. This would mean there’s no way of creating alpha sprites specifically for rectangular pixel modes.

Ignored by the Wimp? Or can’t be created in the first place?

If we want to keep the suffixes at two characters, I’d prefer changing it so that there’s only one character used for specifying DPI instead of two. This would mean there’s no way of creating alpha sprites specifically for rectangular pixel modes.

Ignored by the Wimp? Or can’t be created in the first place?

Ignored by the Wimp.

Coming late to this discussion, so feel free to ignore, but I prefer Jeffrey’s original proposal for the ‘A’ sprites (i.e., !Sprites, !SpritesXY, !SpritesAXY, etc.). It’s a nice logical scheme, and the 10-character limit thing on older OSes won’t break anything as long as alpha sprite tests are skipped.

I’d also vote for the ‘A’ flag to refer only to alpha mask sprites. That way, application authors can provide ‘A’ sprites for both ROL and ROOL’s OS, and not worry about compatibility. That will create a memory overhead, but app sprites are normally fairly small.

Anyone have any more thoughts on this? If not I’ll probably have a go at implementing it sometime in the next few days.

So far the consensus seems to be:

• The ‘A’ flag only indicates alpha mask support
• We’ll stick to two character suffixes (!SpritesXY, !SpritesAX, etc.) to avoid issues on old filesystems

Could we not stick with the existing sort-of-a-precedent (it isn’t very common, but only because alpha sprites aren’t very common) of replacing the ! character with an A to indicate alpha-ness, and keeping the existing two character suffixes? This would conflict with the various 4Sprites and 5Sprites files around, but since neither of those were ever enforced by the OS, they could be renamed if necessary. (And arguably, in the cases where such files are considered necessary, such as with Configure plugins, it really should be the job of the theme manager instead!)

So far the consensus seems to be: The ‘A’ flag only indicates alpha mask support. We’ll stick to two character suffixes (!SpritesXY, !SpritesAX, etc.) to avoid issues on old filesystems

Sounds good to me.