Proposed GraphicsV enhancements

1cs over one call. Of course, ColourTrans caches the 32K-style tables,

Ah, well there’s the thing. If the calls are cached, and ColourTrans is smart enough to retrieve from cache, then it matters less which algorithm is used as unless something fruity is going on, you’ll probably be looking at the same palette info.

an ARM2 takes around 20s to generate a 32K table,

…which is how likely in practice given an ARM2 won’t run anything 32 bit, you can’t reasonably softload RISC OS 5 on an ARM2 (what with 4Mb onboard as a sane maximum), and there is no way you’d extract 32K colours out of a VIDC1. 1cs vs 20s. It’s a nice statistic, at least. ;-)

Yes, for an appropriate definition of “soon”.

I’ll look forward to it. Big merges? Are other people actively poking the same bits you are poking?

there is no way you’d extract 32K colours out of a VIDC1

It’s not about extracting 32K colours out of a VIDC1, it’s about mashing 32K colours into it. The 32K colour tables are used to map 32K/16M sprites down to palettes so that they can be drawn on palettised displays.

But you’re still right about it probably not working on VIDC1. ColourTrans relies on OS_ReadModeVariable to examine the sprite mode word, so RISC OS 3.5 format sprite mode words (required for 32K/16M sprites) will only work on RISC OS 3.5+, and the newer mode word format I’ll be adding will only work on RISC OS 5.21+. (The code I used for doing the performance tests and verifying the behaviour of the algorithm was just using BASIC assembler)

I’ll look forward to it. Big merges? Are other people actively poking the same bits you are poking?

Probably not, but in total I’ll be poking quite a few different components. Potentially anything which deals with sprites or the screen.

Maybe a daft question but is it possible to have the screen & desktop rendered using the Artworks or draw formats so that we can have vector rendering and scalable desktops
similar to dare i say it Apple.

Maybe a daft question but is it possible to have the screen & desktop rendered using the Artworks or draw formats so that we can have vector rendering

That would be really slow, unless it cached the vector graphics as bitmaps.

How about alpha channel support?

How about alpha channel support?

ROL’s alpha sprite mask format? I’ll probably add support for that if/when I get around to improving my current support for alpha pixel formats. At the moment SpriteExtend is just doing the bare minimum to keep an alpha blended framebuffer happy (i.e. there’s no actual blending calculations taking place, all it does is transfer the sprite pixel alpha channel if there is one), so there’s plenty of room for improvement.

so there’s plenty of room for improvement.

Coming soon to a screen near you – RISC OS Aero.

Okay, okay, I’m leaving…

don’t we all ready have a system for cached artworks & draw files? is it slower because the calculations needed to render the icons
when i was asking i was not thinking of multi layed files.

ROL’s alpha sprite mask format?

Perhaps. Either that or an RGBA style format. Either way it would be nice to have alpha blending support in the OS.

NetSurf currently needs Tinct to render PNGs with alpha channels correctly, but Tinct doesn’t work on modern systems.

If RISC OS supported the same alpha channel format as Tinct, then people using NetSurf with the “Use OS” setting for image rendering would get working alpha channel support.

From the Tinct Help file:

Whereas for normal sprites the sprite image would be a series of colour words of the format RrGgBb00, alpha-blended sprites use the empty byte to specify the alpha value, ie RrGgBbAa.

The alpha values represent the blending level on a linear scale where 0×00 represents that the source pixel is totally transparent and 0xff that it is totally opaque. It should be noted that as a standard 32bpp sprite (eg as created with !Paint) will have the alpha channel set to 0×00 by default no output will be visible when plotting as an alpha-blended sprite.

It should be noted that as a standard 32bpp sprite (egas created with !Paint) will have the alpha channel set to 0×00 by default no output will be visible when plotting as an alpha-blended sprite.

Ought to be an easy fix, at least.

NetSurf currently needs Tinct to render PNGs with alpha channels correctly, but Tinct doesn’t work on modern systems.

If RISC OS supported the same alpha channel format as Tinct, then people using NetSurf with the “Use OS” setting for image rendering would get working alpha channel support.

Tinct’s system sounds similar/identical to the RGBA sprite format that I’ll (at least partially) be adding support for. I’ll have to check the docs/code myself, but I’m assuming Tinct just creates a standard 32bpp sprite rather than defines its own sprite type/format. In which case, once the new format is implemented, I think all you’d need to do in NetSurf is make sure the sprites are created as our new RGBA type, and perhaps use a slightly different OS_SpriteOp call (although judging by ROL’s docs, they enable alpha blending for alpha-masked sprites by default – so we should probably follow suit for RGBA sprites)

I’ll bump alpha blended rendering higher up my priority list, since it sounds like it’ll be useful to you.

Having checked the docs, yes, Tint just uses a standard 90×90 dpi 32bpp sprite mode word.

You can test in NetSurf by setting the image Choices to “Use OS”.

1. Choose “Choices…” NetSurf’s iconbar menu.
2. Go to “Images” section.
3. In the Image quality section, choose “Use OS”* for foreground and background images.
4. Visit http://www.libpng.org/pub/png/png-rgba32.html

[*] Options are: “Use OS”, which doesn’t use Tinct; “Direct to screen”, which uses Tinct, so supports alpha, but doesn’t do anything to improve the rendering on <32bpp screens; “Dithered”, which uses Tinct, so supports alpha, and it does a patterned dither, looking better in <32bpp screens; and “Error diffused”, which uses Tinct, so supports alpha, and it does FS error diffusion, so it looks best in <32bpp screen modes. If you’re in a 32bpp screen mode, and you use one of the Tinct rendering options, you’ll just get “Direct to screen”.

Alpha sprites would be great! It would be particularly nice to be able to create background-blended application icons, so they don’t look strange when pinned to non-light-grey Pinboards.

Does anyone have any experience with the version of !Paint supplied with RISC OS 6? What features does it have for editing alpha masked sprites?

I haven’t made much progress the past few days, I’ve been too busy with work stuff. But if I can sort out font blending this weekend, I think that’s the last thing I need to fix which does colour calculations manually. So then I should be able to start work on the new sprite formats sometime next week (including full alpha blending, it looks like)

I don’t know about ROL’s Paint.

If you want to be able to create sprites with alpha channels, you can load a PNG with an alpha channel into NetSurf, and export it as Sprite. The sprite should have the alpha channel values instead of 00.

Thanks for the tip – should be an easy way for me to get some test images, all I’d need to do is some minor hacking of the sprite mode word so the OS will detect it as an alpha sprite.

Progress update: I’ve managed to escape from work long enough this weekend to get basic support for the new sprite formats pretty much finished. So that’s support for ROL’s 64K sprite type, partial support for alpha masks (the OS should know how to manipulate them, but there’s no support for rendering with them yet), and support for the new RISC OS 5 style sprite mode word.

After checking ROL’s docs it looks like their support for rendering alpha blended/translucent sprites relies quite heavily on their BlendTable module (which produces lookup tables for blending between two palettes at a given transparency level). So I think my next task will be to implement a clone of that, then add support for translucent sprite rendering (i.e. same alpha value over entire sprite), and then the full alpha blending with alpha masks/alpha channels. But first, I’m going to start checking some of my changes in, since I’ve reached a point where things are fairly stable and some of the modules might not need touching again.

ROL’s docs

I guess you’ve also had a bit of a browse through Justin Fletcher’s Rambles?

So that’s support for ROL’s 64K sprite type, partial support for alpha masks (the OS should know how to manipulate them, but there’s no support for rendering with them yet), and support for the new RISC OS 5 style sprite mode word.

Sounds good!

rendering alpha blended/translucent sprites relies quite heavily on their BlendTable module

I think ROL used that to make various look-and-feel improvements to update the desktop a little. For instance, when you drag an icon/sprite on RO5 it uses a “checker board” mask to fake translucency, but ROL made dragged icons render with proper translucency, and even made it look good in low colour screen modes. ROL also improved the look of faded-out (unavailable for clicking) WIMP buttons by making them fade out to the window background colour (grey), rather than to white.

ROL’s docs

I guess you’ve also had a bit of a browse through Justin Fletcher’s Rambles?

Yes, I had a quick look this morning. I’ll have to try and track down some docs for the InverseTable_SpriteTable SWI – I don’t remember seeing it mentioned anywhere in ROL’s online docs.

rendering alpha blended/translucent sprites relies quite heavily on their BlendTable module

I think ROL used that to make various look-and-feel improvements to update the desktop a little. For instance, when you drag an icon/sprite on RO5 it uses a “checker board” mask to fake translucency, but ROL made dragged icons render with proper translucency, and even made it look good in low colour screen modes. ROL also improved the look of faded-out (unavailable for clicking) WIMP buttons by making them fade out to the window background colour (grey), rather than to white.

Icon dragging definitely uses BlendTable (by way of DragASprite, by way of SpriteExtend’s translucent sprite support), but for greying out buttons I think they might be using another new feature (colour mapping). I guess it’s all down to whether they’re fading them to grey or whether they’re fading them to the background colour (i.e. actually blending with the background pixels). Either way, I suspect I’ll be adding colour mapping support at some point, and will probably have a go at implementing the blending/colour mapping related Wimp look-and-feel stuff (since it should be pretty straightforward once support in SpriteExtend is in place)

I guess it’s all down to whether they’re fading them to grey or whether they’re fading them to the background colour (i.e. actually blending with the background pixels).

Hmm, I think it blended to the flat window background colour, not to the underlying window texture.

Either way, I suspect I’ll be adding colour mapping support at some point, and will probably have a go at implementing the blending/colour mapping related Wimp look-and-feel stuff (since it should be pretty straightforward once support in SpriteExtend is in place)

Cool. When it comes to rendering, it probably needs to be able to handle two opacity values per pixel. For example if we had application icons with alpha channels, and you drag an icon, the sprite’s alpha channel values need to be merged with whatever you do for dragged sprites (a flat 50% opacity, or something).

when you drag an icon/sprite on RO5 it uses a “checker board” mask to fake translucency

I was quite shocked when I realised RO5 doesn’t do that!

I’ll have to try and track down some docs for the InverseTable_SpriteTable SWI

I can make some if you need some.

for greying out buttons I think they might be using another new feature (colour mapping). I guess it’s all down to whether they’re fading them to grey or whether they’re fading them to the background colour (i.e. actually blending with the background pixels)

The parenthetical bit is a non sequitur. They are fading to the window background colour, they are not blending background pixels (and if the window background is ‘none’, it uses white). Note that colours are greyscaled first before tinting towards the background colour.

So for drawn, textual and paletted sprites no blending code is required, just a bit of simple maths when calculating the colours or palette. For 16bpp and above into paletted modes SelectTable’s transfer function is enough. For deep sprites into deep modes something will have to be done unless the Wimp fakes it with a temporary sprite (and bearing in mind the monochromatic palette, there’d be no quality loss).

Mind you it’s not just shaded icons, selected sprite icons also get their colours modified – faded to white. This happens before the shaded fade.

I’ll have to try and track down some docs for the InverseTable_SpriteTable SWI

I can make some if you need some.

There’s a starting point¹ on ROL’s site.

¹ Which may or may not be what you’re referring to

Cool. When it comes to rendering, it probably needs to be able to handle two opacity values per pixel. For example if we had application icons with alpha channels, and you drag an icon, the sprite’s alpha channel values need to be merged with whatever you do for dragged sprites (a flat 50% opacity, or something).

Yes, that’s what I’m aiming for.

For deep sprites into deep modes something will have to be done unless the Wimp fakes it with a temporary sprite (and bearing in mind the monochromatic palette, there’d be no quality loss).

AIUI that “something” is the colour mapping support that ROL added (it’s exactly like the transfer function you supply to ColourTrans_SelectTable/GenerateTable, except you give it directly to SpriteExtend so it can use it on true colour sprites)

There’s a starting point on ROL’s site.

That’s the one! I was foolishly expecting InverseTable docs to be on a page with InverseTable in the title, not in the ImageFileRenderer docs.

it’s exactly like the transfer function you supply to ColourTrans_SelectTable/GenerateTable, except you give it directly to SpriteExtend

I know.

InverseTable is extremely simple and has two trivial optimisations of recognising the same palette passed in again, and the standard 256 colour palette.

Other than that it’s a simple error-minimising linear search, and the implementations I have seen aren’t totally optimal.