Proposed GraphicsV enhancements

It took a bit of time to sort through everything, but the first batch of changes are now in CVS. This covers:

• Adding support for OS_ScreenMode 13 (Mode string to specifier), 14 (mode specifier to string), and 15 (set mode by string). Mostly as per ROL’s specs, but minus support for teletext attributes, and plus support for new RISC OS 5 attributes (L… layout specifier, 4096 & 24bpp packed modes, etc.)
• Basic kernel & SpriteExtend support for sprites with alpha channel masks
• Support for 64K colour sprites & new RISC OS 5 style sprite mode word (and relevant sprite formats)
• Support for new screen modes (4K colour, 64K colour, RGB/BGR order, alpha channel)
• The new faster ColourTrans_SelectTable/GenerateTable algorithm
• Supremacy font blending (for blending fonts into a framebuffer with a supremacy channel, enabled when bit 14 of Font_Paint is set) extended to add support for alpha blending (if framebuffer has alpha channel) and for operation in 4K colour modes (old code only supported 16M colour modes. 32K colour modes is a possibility but somewhat pointless as there’ll only be two alpha/transparency levels)
• SpriteExtend scaled/transformed sprite & (scaled) JPEG rendering improved to cope with new sprite formats & screen modes. The generated plotting code should generally bit a bit faster than before, and at least one bug with false-positives on code matching has been fixed (I can’t remember the exact details, but I think it came down to the dithering option not being taken into account correctly – so if you render a dithered sprite followed by an undithered one, they’d both end up being rendered dithered).
• Paint updated to not explode when given an unknown sprite type
• *WimpMode now uses OS_ScreenMode 13 if available

I think that’s about it. Note that there aren’t any GraphicsV changes yet. Video drivers won’t understand the new modes, and there’s no way of selecting them through the display manager, but because the rest of the OS knows about them it’s possible to (e.g.) do “*WimpMode X640 Y480 C16M LTRGB” to get a correctly red/blue swapped output on a BB’s TV-out.

Let me know if you spot anything odd – it’s entirely possible I’ve broken something!

It took a bit of time to sort through everything, but the first batch of changes are now in CVS. This covers:

I built an OMAP4 rom with your latest changes. Everything is working Ok apart from the !NetSurf icon doesn’t display correctly. It’s affecting the !netsurf and sm!netsurf in the ASprites22 file.
I also tested creating a 64K sprite with and without alpha mask using the RISC OS 6 version of !Paint. These successfully loaded and displayed in the new version of !Paint.

Supremacy font blending

What is that?

Everything is working Ok apart from the !NetSurf icon doesn’t display correctly. It’s affecting the !netsurf and sm!netsurf in the ASprites22 file.

The ASprites* files use the ROL-type separate alpha mask. If you’re using an older version of NetSurf, it decides whether to use the !Sprites*, 5Sprites*, or ASprites* variants based on SpriteExtend module version. Recent versions run a little ChkSprites BASIC program in NetSurf’s !Boot file to determine which variant is appropriate.

Recent versions run a little ChkSprites BASIC program in NetSurf’s !Boot file to determine which variant is appropriate.

I’m using version 1305 of !Netsurf. I’m now getting a hang as soon as the !NetSurf !Boot file is executed.
As a temporary workaround I’ve commented out the ‘ChkSprites’ line in the !Boot file.

Supremacy font blending

What is that?

For blending fonts into framebuffers which use supremacy. Looks like it was introduced in version 3.60 of the font manager, probably for an STB project:

Added support for supremacy blending in 32bpp modes only. If bit 14 is set
in Font_Paint as well as bit 11 (for blending), then the blending takes into
account the supremacy bits of the screen data when compositing. If not in a
32-bpp mode, then an error is returned.

In addition, when bits 11 and 14 are set, the supremacy bits in the chosen
foreground colour (set via ColourTrans_SetFontColours or similar) are used,
so you can plot semi-transparent text. This is a limited facility - it's
not available below 32bpp, and it doesn't work for text above FontMax2.

Also, fixed a bug which meant that successive paints with different blending
flags had to be separated by colour-setting calls to get the new flags to
be obeyed.

Note that, as in previous versions, the blending still doesn't correct for
gamma.

I’ll probably be wanting to implement a similar feature in SpriteExtend so that we can blend sprites with alpha-blended overlays correctly (and supremacy-blended overlays, I guess – although RISC OS’s support for supremacy is somewhat patchy)

Recent versions run a little ChkSprites BASIC program in NetSurf’s !Boot file to determine which variant is appropriate.

Ah, that’ll be why my rather old version didn’t show the issue.

But yeah, the problem is that although alpha mask sprites will load OK, I haven’t taught SpriteExtend how to render them properly yet – so it’s trying to treat it as a 1bpp mask. Interesting that version 1305 hangs – I’ll have to take a look at that, as that sounds a bit more serious.

Also interesting that a 64k sprite you created with an alpha mask appeared to render correctly – are you sure !Paint didn’t strip out the alpha mask when you saved the file? (I’m assuming you did something interesting with the mask so that there was some actual transparency there!)

I’m using version 1305 of !Netsurf. I’m now getting a hang as soon as the !NetSurf !Boot file is executed.

No crash for me, I’m afraid. If I can’t get to the bottom of it in the next day or two I think I’ll temporarily make the validate sprite area OS_SpriteOp complain if it finds an alpha-masked sprite – that’ll stop Netsurf (and hopefully any other software) from trying to use the sprites until I can fix the bug. In fact, I’ll probably leave it in there until rendering is fixed too.

No crash for me either.

Last night I decided that my new !Boot installation was correct, so I flashed 5.20, then installed the currently available 5.21 as a softload. I loaded up NS 1305 JS, expecting a lock, but it worked fine.

Which machine? There was a problem yesterday which meant it was only new OMAP ROMs which were built containing my changes. That’s been fixed now, so the latest ROMs for all platforms have my changes.

Hopefully I’ll find the time to update my Iyonix’s !Boot to the new 5.20 one in the next few days, that should make testing some things a bit easier.

Also interesting that a 64k sprite you created with an alpha mask appeared to render correctly – are you sure !Paint didn’t strip out the alpha mask when you saved the file? (I’m assuming you did something interesting with the mask so that there was some actual transparency there!)

I just used the RISC OS 6 version of Paint (2.70) to create the 64K Sprite with ‘Full alpha Channel’ ticked. In this version the info for the Sprite shows ‘has alpha channel’
The RISC OS 5 version shows ‘has mask’.

No crash for me, I’m afraid. If I can’t get to the bottom of it in the next day or two I think I’ll temporarily make the validate sprite area OS_SpriteOp complain if it finds an alpha-masked sprite – that’ll stop Netsurf (and hopefully any other software) from trying to use the sprites until I can fix the bug. In fact, I’ll probably leave it in there until rendering is fixed too.

No problem.
I’ve done a quick test of all the different combinations of Mode strings. No problems to report apart from funky desktop colours in 4K and 64K.

Progress update: I had a fair amount of spare time this weekend, so was able to get sprite blending pretty much fully working. This is for both the ‘translucency’ argument to OS_SpriteOp and support for alpha channels/masks. There’s a bit of tidying up left to do, but also one fairly major problem to solve – when blending is being used there are a few situations (mainly when dealing with masked sprites) in which SpriteExtend’s plotter generator will run out of registers and give up (resulting in nothing being rendered). I’ve run into this problem quite a bit when trying to get the code working, but as more and more features are added it’s turning into a losing battle. So I think I’m going to have to try overhauling the way SpriteExtend handles register allocation, so that the code doesn’t have to be littered with special cases to deal with running out of registers in certain situations (and to fix issues where the workspace pointer gets allocated to something, but then must be used again as the workspace pointer later on). Once that’s done it should be pretty easy to get blending working with JPEG plotting and transformed sprite plotting (currently it’s only the scaled plotting which has it enabled).

I’m also thinking of creating a fully automated test program to check that all the plotter combinations work OK. Basically something which redirects screen output to a sprite, plots various test pattern sprites, and then compares against either a known-good result sprite or against its own model of what it expects the result to be.

Hi Jeffrey, sounds great.
I’m not sure if this is at all related but one thing that stands out to me on the Raspberry PI desktop is the grey rectangle around the text of pinboard items. I’m used to RISC OS six which doesn’t have the grey rectangle the text appears to be masked and the text blended with it.
The more I think about the more I suspect it won’t share any of the same code as sprite blending.

I think there’s a very good argument for having no dynamic code generation at all. Certainly at the time the Iyonix was launched the code generation was the only thing I could think of to account for how much slower the OS’s sprite routines were than Vantage’s drawing engine (that was doing far more).

We’re not short of ROM bytes. Or at least make the code generation the fallback when a dedicated (and optimised) plotter isn’t available – then (for now) just code the problematic ones. Dedicated code will always be faster than generated code even disregarding the expensive SynchroniseCodeAreas call.

I’m not sure if this is at all related but one thing that stands out to me on the Raspberry PI desktop is the grey rectangle around the text of pinboard items. I’m used to RISC OS six which doesn’t have the grey rectangle the text appears to be masked and the text blended with it.
The more I think about the more I suspect it won’t share any of the same code as sprite blending.

Possibly related to WimpVisualFlags not being set correctly? (Disclaimer: Without checking on a machine I’m not entirely sure if the RO 5 pinboard supports blending the text like that)

I think there’s a very good argument for having no dynamic code generation at all. Certainly at the time the Iyonix was launched the code generation was the only thing I could think of to account for how much slower the OS’s sprite routines were than Vantage’s drawing engine (that was doing far more).

Dynamic code generation isn’t ideal, but considering the number of different plotter combinations there are (sprite types, screen types, masks, blending, translation tables, scale factors, GCOL actions, double-pixel modes, dithering, available CPU instructions, etc.) I think we’d have a hard time getting rid of it. And if we aren’t allowed to use a code generator to generate the plotters, who in their right mind would want to create and hand-optimise all those cases?

Hand-optimising some of the routines is a possibility, but if it’s possible for us to spot ways the code can be optimised then I’d prefer to try and build those optimisations into the generator itself – that way everyone will benefit instead of just those who are using the right screen mode & sprite types.

I’m not sure if this is at all related but one thing that stands out to me on the Raspberry PI desktop is the grey rectangle around the text of pinboard items. I’m used to RISC OS six which doesn’t have the grey rectangle the text appears to be masked and the text blended with it.
The more I think about the more I suspect it won’t share any of the same code as sprite blending.

Possibly related to WimpVisualFlags not being set correctly? (Disclaimer: Without checking on a machine I’m not entirely sure if the RO 5 pinboard supports blending the text like that)

I can confirm it is fixed by the configure utility that Rick Murray points to on that page.

“Brief” progress update to say that I managed to find a solution to the register allocation problem without having to rewrite too much. Instead of the previous system where registers would be allocated on a first-come, first-served basis, it now builds a list of which registers need allocating and then allocates them all in one go, using the supplied usage flags to work out how to handle situations where there aren’t enough physical registers available and some need to be reused and/or saved to the stack. There are still a few tweaks I need to make to improve the code, but it looks like it will cope OK with everything we need to throw at it. And an extra benefit of the tighter control over register allocation is that the compiler now knows which logical registers are active at any particular time – so if you try accessing a register when it’s in an inactive state (i.e. saved to the stack) it’ll assert instead of generating broken code.

Now that that’s out of the way, by the end of this weekend I should hopefully have all the remaining SpriteExtend-related blending issues fixed – i.e. blending fully working for scaled & transformed sprites and (scaled) JPEGs. Then there are only a few bits to tidy up elsewhere (including finding that crash bug people were seeing) before I should be able to check the code in.

How about then taking a bit of a breather at RetroMission?

RetroMission – I’d like to see cosplay pics, especially if somebody turns up as a pixelated Chuckie Egg! :-)

I have a Chuckle Egg t-shirt, but that’s cheating rather than proper cosplay. And anyway, the pixel proportions don’t look like the beeb version (it’s just the farmer) and is probably taken from the speccy.

Progress update: Colour mapping is now implemented for sprites. JPEGs don’t support it yet, but that should change before I check everything in. So once that’s out of the way, I think it will mean that our version of SpriteExtend will support all of the rendering modes that ROL’s version supports – the only remaining discrepancies are CMYK support (which I’ll most likely leave until some future date), and any extra utility SWIs/SpriteOps (e.g. alpha mask promotion/demotion, which I’ll be implementing “soon”).

At the moment my focus is on bug fixing. I’ve put together a test app for testing all the different sprite/screen/option combinations. It looks like I need to tune the error tolerances a bit more to avoid some false positives, and tweak it to use some more human-friendly test images (spotting what’s wrong when a sprite containing random noise is plotted into a screen containing random noise is a bit tricky!), but once that’s done it should do a pretty good job of finding bugs that are hidden in the renderer. E.g. when testing against an older version of SpriteExtend on my Iyonix I’ve already spotted a couple of cases where it wasn’t dealing with double-pixel modes properly, and some of the GCOL actions appear to be broken.

The following changes are now checked in:

• The Kernel OS_SpriteOps for plotting sprites/masks (28, 34, 48, 49) have been fixed so that they properly throw an error when asked to plot alpha-masked sprites (before they would get stuck in an infinite loop – I’m fairly certain this would have been the random hangs people were seeing). I’ve also fixed a couple of issues with plotting of RISC OS 5 type sprites.
• OS_SpriteOp 43 & 44 (read/write pixel mask) have been fixed to work properly with alpha masks
• OS_ScreenMode 13 & 14 now handle “G2” properly for specifying a mode with 2 grey levels (before they’d throw an error, as I’d forgotten to implement it)
• The InverseTable_SpriteTable SWI has been added, as per ROL’s spec
• The BlendTable clone has been added to the ROMs
• SpriteExtend has been updated so that OS_SpriteOp 52 (put sprite scaled) & 56 (plot sprite transformed) support colour mapping descriptors, translucent rendering, and alpha blending of alpha-masked or alpha-channel sprites, as per ROL’s specs. I’ve also disabled the code I put in OS_SpriteOp 17 (verify sprite area) which was deliberately faulting alpha-mask sprites, as the crashes are hopefully fixed now and rendering is fully implemented too. Plus assorted bug fixes for the rendering bugs I’ve been finding.
• JPEG_Plot[File]Scaled and JPEG_Plot[File]Transformed have also been updated to add colour mapping & translucency, as per ROL’s specs
• And finally as a bit of eye candy, DragASprite now uses translucent rendering for the dragged sprite, just like ROL’s version does. However there is the exception that it will fall back to using the old mask dithering/hatching approach in 1bpp modes, unlike ROL’s version which (judging by their docs at least) still tries to use blending – which I can’t imagine works very well.

As always, let me know if you spot anything odd happening!

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.

If anyone wants to have a go at getting NetSurf to use the 32bpp &AABBGGRR sprite format, try changing the sprite mode word that’s being used to &78608051. Alpha blending using the alpha channel should then work using OS_SpriteOp 52 as long as you have bit 8 bit 3 of R5 set (the ‘use mask’ bit). You might also want to add some code to detect if RISC OS 5 type sprites are actually supported – e.g.

bool riscos5_supported = (_swi(OS_ReadModeVariable,_INR(0,1)|_RETURN(2),0x78608051,0) == 0x8000);

That (should) verify that the kernel decodes the mode flags correctly from the sprite mode word. Also if NetSurf can detect which sprites do and don’t actually contain alpha then either disabling bit 8 bit 3 of R5 or using a non-alpha sprite format for those sprites is advisable, so that the overheads from the blending code can be eliminated

The following changes are now checked in:

Awesome work as usual. I’ll look forward to testing this once the nightly batch process has run.

Is there any part of the OS that you haven’t actually touched yet?! It seems like you’ve pretty much improved every nook and cranny of the RISC OS.

Great work, Jeffrey! Look forward to trying it all out!

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 knew it would be too good to be true that my testbed would have found all the major bugs! Hopefully I’ll be able to find the problems on my BB (although that’s what I was using for most of the testing so far).

What screen mode have you been seeing the problems in? 16M colours? Also if you (or anyone else) gets another abort, it would be useful to have the output of:

*showregs
*memoryi pc-40 + 80

That should be a big help in tracking it down, especially in cases where it’s a crash in the generated code.

I think I might also put together a debug version of SpriteExtend so that people can generate a log for me if they find a reproducible problem.

I’ve had a go with it, and it’s looking good. :)

And finally as a bit of eye candy, DragASprite now uses translucent rendering for the dragged sprite, just like ROL’s version does.

It would look better without the drop shadow. IIRC ROL’s didn’t do the drop shadow.

If anyone wants to have a go at getting NetSurf to use the 32bpp &AABBGGRR sprite format, try changing the sprite mode word that’s being used to &78608051. Alpha blending using the alpha channel should then work using OS_SpriteOp 52 as long as you have bit 8 of R5 set (the ‘use mask’ bit).

I’ve just had a look. It turns out that in the “Use OS” case, NetSurf still uses Tinct, and it’s Tinct that plots it with OS_SpriteOp. When asked to do an alpha plot with the OS, Tinct creates a copy of the image pre-blended to a background colour, which the OS then plots.

I think we’ll either need to get Tinct to support OS_SpriteOp versions that can do alpha plots, or update NetSurf to handle the “Use OS” options itself. There is some code for using OS_SpriteOp in there, but it doesn’t look like it handles tiling (e.g. for repeating background images).