Proposed GraphicsV enhancements

Minor correction for anyone who does decide to try alpha blending via OS_SpriteOp: It’s bit 3 of R5 you want to set, not bit 8.

With the latest OMAP4 rom the screen redraw with the NetSurf icons !netsurf and sm!netsurf doesn’t seem to be working correctly. The sm!netsurf icon doesn’t show up in the filer window at all.

I’ve also had one abort from spriteextend although I haven’t been able to reproduce it,

Address &FC27B9CC is at offset &00000CC8 in module SpriteExtend

I’ve checked in fixes for the netsurf icon rendering funny (if they were obscured it was calculating the wrong offset into the sprite data) and sm!netsurf vanishing (the Wimp was being clever and trying to use the kernel OS_SpriteOps where possible for speed – but hadn’t been taught about the new sprite types so was trying to ask the kernel to render an alpha-masked sprite, which it doesn’t support)

The crash you got is a bit of a funny one – it looks like it crashed in OS_SpriteOp 37 (create/remove palette), while trying to read the palette size, due to a bad sprite pointer. So without a reproducible case I don’t think much can be done to fix that one, as it’ll most likely be somewhere else where the real problem is.

I’ve checked in fixes for the netsurf icon rendering funny (if they were obscured it was calculating the wrong offset into the sprite data) and sm!netsurf vanishing (the Wimp was being clever and trying to use the kernel OS_SpriteOps where possible for speed – but hadn’t been taught about the new sprite types so was trying to ask the kernel to render an alpha-masked sprite, which it doesn’t support)

It’s working Ok now. Thanks.

The crash you got is a bit of a funny one – it looks like it crashed in OS_SpriteOp 37 (create/remove palette), while trying to read the palette size, due to a bad sprite pointer. So without a reproducible case I don’t think much can be done to fix that one, as it’ll most likely be somewhere else where the real problem is.

I was using the RISC OS 6 version of paint to create some test alpha channel sprites. The abort happens when clicking on a sprite in the list of sprites loaded in !Paint. So probably nothing to worry about.

Jeffrey, this looks excellent. Really improves the feel of the desktop with the translucent drags. I’d second Michael’s comment about losing the 3D drop shadows on the icons.

Latest addition: OS_SpriteOp 38. Should basically be the same as ROL’s version, except it can also convert to/from alpha channels.

I’ll have a think about the DragASprite drop shadows. When someone calls DragASprite_Start they need to explicitly request that the drop shadow is used, which means the “correct” way of dealing with it would probably be to update everything which uses DragASprite to stop requesting drop shadows if blending is in use. But that would just mean any OS-initiated drags (e.g. filer) would have the drop shadows disabled, while everything else (e.g. saveas boxes in third-party apps) would have them enabled, which would make things look a bit odd. Plus there’s no simple way of working out if blending is going to be used (especially if you want your software to behave as expected on ROL’s version of the OS). Unless of course someone can confirm that the drop shadow flag is ignored by ROL’s DragASprite?

Can the RO5-style sprite mode words still be passed into OS_ReadModeVariable, to save us from the nightmare of disentangling four divergent implementations of those 32 bits for ourselves?

Can the RO5-style sprite mode words still be passed into OS_ReadModeVariable, to save us from the nightmare of disentangling four divergent implementations of those 32 bits for ourselves?

Yes, although you obviously need a suitable version of RISC OS 5.

For the past few weeks I’ve been slowly working my way through the wiki updating everything related to screen modes and OS_SpriteOp (and learning new stuff in the process!). For example OS_ReadModeVariable (and most other mode-related APIs) actually accepts what’s called a ‘mode specifier’, which can be a mode number, sprite mode word, or mode selector block (not to be confused with mode provider blocks, which are used by Service_EnumerateScreenModes. And not to be confused with “mode specifier blocks”, which is an incorrect term for selector blocks I’ve seen used in some docs)

Good on you for making a point of updating the wiki, Jeffrey. One thing I don’t quite understand is what it says about the Mode Specifier:

A mode specifier is a single-word value used to specify a screen mode. It is handled as follows:
* If it is a number from 0 to 255, it is assumed to be a mode number
* If the bottom bit is set, it is assumed to be a Sprite Mode Word (describing a RISC OS 3.5 or RISC OS 5 format sprite)
* Otherwise it is assumed to be a pointer to a Mode Selector Block

How can you tell the difference between odd-numbered mode numbers and Sprite Mode Words?

If you perform the tests in order you’ll arrive at the right outcome.

But on the other hand, mode numbers are valid sprite mode words, so maybe the answer should be that you can’t tell the difference :)

See also the “Determining mode word format” section of the sprite mode word page

Unless of course someone can confirm that the drop shadow flag is ignored by ROL’s DragASprite?

Confirmed.

Jeffrey also wrote (in separate posts, so I’ll let him off):

If it is a number from 0 to 255, it is assumed to be a mode number

mode numbers are valid sprite mode words

It might be less ambiguous to say that 0-127 are valid mode numbers. 128-255 Are an obsolete way of selecting the same modes with a shadow bank on systems that support them, but are not valid sprite modes (Paint can get confused, for a start).

Is it just me or does the direction of the directory drop shadow make sprites look as if they’re lying down?

If you perform the tests in order you’ll arrive at the right outcome.

Got it! Thanks for the explanation.

Unless of course someone can confirm that the drop shadow flag is ignored by ROL’s DragASprite?

Confirmed.

Cheers. I’ve now modified our DragASprite to behave in a similar way, ignoring the flag if a translucent drag is being performed.

Personally I’m not too sure about which I like best – I’m thinking that maybe a smaller (1 or 2 pixel?) drop shadow would look better than none, just to make the dragged sprite stand out a bit more. But drop shadows also cause problems with sprites which have been manually blended to the standard window background colour (e.g. the standard RO 5 directory icon seems to suffer from this a bit) – so maybe it is best left disabled.

At some point I’ll also need to update it to deal with alpha-mask/alpha-channel sprites and alpha-channel screens properly. Plus there are some redraw issues in the filer with alpha masked sprites (keep selecting & deselecting the netsurf icon and the edges will get darker and darker because the filer isn’t redrawing the background before drawing the sprite on top)

Personally I’m not too sure about which I like best – I’m thinking that maybe a smaller (1 or 2 pixel?) drop shadow would look better than none, just to make the dragged sprite stand out a bit more.

I don’t think a drop shadow would look good at all, unless perhaps a diffuse-edged alpha shadow. Also, the shadow should be visible through the translucent sprite, or it looks weird.

I can’t remember exactly what ROL’s implementation did, but I do remember thinking it looked perfect. Maybe making the dragged sprite have, say, 60% opacity would look better than 50/50?

Edit: Just tried the latest ROM, without the shadow. Looks great to me. :)

drop shadows also cause problems with sprites which have been manually blended to the standard window background colour

One of the great opportunities opened up by this change is to – eventually – revise app icon sprites to blend into an arbitrary colour background. I believe the RO5 icons all still exist in ArtWorks versions somewhere. Not sure if current versions of ArtWorks allow for the export of alpha-mask sprites, but if that feature is added, it’d be a relatively easy (if repetitive) task to update them.

In terms of 3rd-party applications wishing to make use of alpha sprites, will *IconSprites at some point be able to load them automatically, rather than the application having to test for appropriate SpriteExtend versions, etc.? It would be nice to be able to supply !Sprites, !Sprites22, etc. and (say) !ASprites, !ASprites22, and let the OS handle which is safe to load.

Not sure if current versions of ArtWorks allow for the export of alpha-mask sprites

It does. Is anyone in touch with Richard Hallas?

in touch with Richard Hallas?

I’ve sent him an email linking above. On a related topic, if the ArtWorks files themselves could be incorporated within the sources, then couldn’t they be rendered as part of the build process? Wouldn’t this facilitate the creation of hi-res sprites?

In terms of 3rd-party applications wishing to make use of alpha sprites, will *IconSprites at some point be able to load them automatically, rather than the application having to test for appropriate SpriteExtend versions, etc.? It would be nice to be able to supply !Sprites, !Sprites22, etc. and (say) !ASprites, !ASprites22, and let the OS handle which is safe to load.

That’s a good idea, yes. I’ll look into it.

Once I’ve tidied up the sprite stuff a bit more I’m hoping to get back to the GraphicsV side of things. My current plan (subject to change) is:

• Finishing up multiple driver support
• Finishing up the new screen mode support
• (Re)implementing multiple head support
• Get the other video drivers updated and get everything checked in

The main aim of the above changes being to get fairly polished support for the Pandora TV-out cable in a reasonable timeframe. Plus it’s about the only sensible place where I’ll be able to get everything checked in prior to starting work on overlay support – which if I’ve played my cards right, shouldn’t require any backwards-incompatible changes to the new APIs. That should also mean there’s nothing stopping the 5.22 release from happening before overlay support is implemented if it looks like my changes are going to drag on for a while.

Looks like there are a couple of differences between the ROL and ROOL DragaSprite. The ROL version takes notice of the Filer Display settings. The text also appears in the drag.

I’m still around, and still at my old email address: speak my name and I may appear!

The RISC OS 5 (including new RISC OS Pi) icons were designed from the outset to be suitable for use with alpha-transparency sprites, and it’s been a disappointment to me that RISC OS 5 has never gained the ability to handle such sprites. It’s always seemed ironic that RISC OS 4 & 6 could handle alpha masks, but had no suitable graphics, whereas RISC OS 5 had suitable graphics but not the facility to handle them.

So, obviously, all the soft shadows in the RISC OS 5 icons are currently just solid pixels, coloured to match an assumed Wimp Grey 1 background. If RISC OS 5 were to gain full support for sprites with alpha masks, then I’d be only too happy to regenerate the entire icon set to take advantage of that feature.

That’s not to say that it would be a trivial task. Although the icons are indeed all vector designs, produced in ArtWorks (though some do have some bitmap elements incorporated), there’s a fair amount of hand-tweaking involved with some of them, especially in the creation of the tall-pixel versions. So it’d be a fair amount of work, but I’ve actually wanted to do it ever since I created the icons back in 2002.

There was mention above of building the ArtWorks files into the sources and having them auto-rendered as part of the build process. Nice idea, but it couldn’t work without a great deal of further effort, because:

1. The ArtWorks sources are not individual one-icon-per-file documents. Rather, there’s a fairly small number of ArtWorks files, each of which contains a large number of icons (e.g. there’s one file for all non-folder-style OS filetype icons), and they’re formed from a great many layers within each document. E.g. for square filetype icons, there’s precisely one corner-curl graphic, on its own layer; one cogwheel overlay (for some system filetypes); one drop-shadow; one set of shading highlights; and so on. The unique aspects of each individual filetype then appear on their own individual layer, which can be made visible before exporting the icon. So, to generate a separate file for each icon would actually be a pretty large amount of work. It would also be pretty inefficient because of the duplication of thousands of copies of various common elements (not that that’s necessarily a concern).

2. Although exporting ‘standard’ Sprites22-style icons from ArtWorks is straightforward, exporting the other variations is not. The high-definition Sprites11-style icons need to have their dpi corrected to 180 as a manual step, and some of them have extra detail compared with their Sprites22 equivalents, so there may or may not be a separate design for the Sprites11 version. As for the tall-pixel Sprites-style icons, they’re a real pain. They may involve their own separate design, and they always require a multi-step editing and conversion process. It might in theory be automated, but that would require a lot of care and may not always produce quite the right results. A fair amount of human judgement has to go into those versions.

Looks like there are a couple of differences between the ROL and ROOL DragaSprite. The ROL version takes notice of the Filer Display settings. The text also appears in the drag.

Interesting. I think that must be a filer change, rather than a DragASprite change – DragASprite only handles a sprite as the drag object, so for anything more complex (e.g. sprite + text) it needs the caller to set up a custom sprite first. I think this is something that DragAnObject makes fairly easy, so I might have a go at implementing it in our filer if I’m feeling nice!

If RISC OS 5 were to gain full support for sprites with alpha masks, then I’d be only too happy to regenerate the entire icon set to take advantage of that feature.

Full support at the OS level is pretty much there – download the latest ROM and give it a go. There’s still a lot of work needed to update !Paint though – at the moment it only really understands the old binary mask format (it’ll let you edit alpha-masked sprites, but you’ll only be able to set the mask to binary on/off values). I’m not sure yet when/if I’m going to have a go at updating Paint myself, since I’ve got a lot of other stuff I want to get done. Also if you’re going to be viewing the sprites in Paint, make sure you grab a fresh copy from the latest hard disc image, as older copies will probably crash when they see the new sprites (unavoidable, unfortunately).

it’s been a disappointment to me that RISC OS 5 has never gained the ability to handle such sprites

Jeffrey has added support for them to RISC OS 5. Both the ROL alpha mask format and a RRGGBBAA format.

ArtWorks can export sprites in the alpha mask format, which is compatible with RISC OS 5 and ROL OS.

I can’t remember exactly what ROL’s implementation did, but I do remember thinking it looked perfect. Maybe making the dragged sprite have, say, 60% opacity would look better than 50/50?

If the API has a bit to say “add drop shadow” then I think a few more trials to honour that flag bit is worthwhile.

Make the shadow less long? Adjusting the ratio of 75% sprite to 25% shadow? Better still, someone with some graphics skill could mock up a few variants first before having to make code changes, but if I ask for a shadow I think I’d expect to get one.

… building the ArtWorks files … auto-rendered as part of the build process. Nice idea, but it couldn’t work without a great deal of further effort

Understood. Thanks for the explanation. It definitely sounds like more effort than it’s worth. (And I’d not considered the inevitable tweaking by hand – although I suppose the ArtWorks originals could possibly be reverse tweaked so that they produce the desired bitmap outputs.)

This is from Justin Fletcher’s Desktop support RISC OS ramble:

Making sprites drag transparently with DragASprite wasn’t actually all that hard – intentionally so, as that’s how the interface had been added to the SWI OS_SpriteOp calls. The call that plotted the sprite was changed from merely plotting it to use a translucency level. That worked reasonably well, but it was obvious immediately that the ‘shadow’ that had been applied to the sprite looked wrong now.

So the shadow got forcibly disabled if the drag was requested to be hatched, which improved things a bit. The drag was still solid if it was requested, though, and in that case the shadow would appear again. Strictly if it were to be a real shadow we should plot a translucent version of the mask behind the sprite, in black. That would give the right effect, but as the purpose of the translucency was to allow you to see where you were dropping the sprite, obscuring it with a shadow would probably be the wrong thing to do.

The translucency itself fell down when in a very low colour mode – 4 and 2 colours really hurt it. Because the translucency level was ‘a little more solid than half and half’ (3/8ths), in 2 colour modes it always appeared solid. In 4 colour modes it was generally solid, but you didn’t have a lot of colours to make the effect work. This bothered me a little, but not enough to change the behaviour based on it – such modes wouldn’t be used by many people, and in any case would not be supported by more modern hardware, so the problem would go away later.

So:

1. The shadow looks wrong with translucent drags. :)
2. It did display the dragged sprite with more than 50% opacity. (5/8ths)
3. It always removed the shadow if a translucent drag was requested.
4. Because of the >50% opacity, in two colour modes it “just works”, generally showing like a solid drag.