Proposed GraphicsV enhancements
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Jeffrey Lee (213) 6048 posts |
It took a bit of time to sort through everything, but the first batch of changes are now in CVS. This covers:
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! |
Chris Gransden (337) 1207 posts |
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. |
Michael Drake (88) 336 posts |
What is that?
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. |
Chris Gransden (337) 1207 posts |
I’m using version 1305 of !Netsurf. I’m now getting a hang as soon as the !NetSurf !Boot file is executed. |
Jeffrey Lee (213) 6048 posts |
Supremacy font blending 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)
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!) |
Jeffrey Lee (213) 6048 posts |
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. |
Dave Higton (1515) 3526 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. |
Chris Gransden (337) 1207 posts |
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’
No problem. |
Jeffrey Lee (213) 6048 posts |
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. |
Chris Evans (457) 1614 posts |
Hi Jeffrey, sounds great. |
nemo (145) 2546 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. 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)
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. |
Chris Evans (457) 1614 posts |
I can confirm it is fixed by the configure utility that Rick Murray points to on that page. |
Jeffrey Lee (213) 6048 posts |
“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. |
Trevor Johnson (329) 1645 posts |
How about then taking a bit of a breather at RetroMission? |
Rick Murray (539) 13840 posts |
RetroMission – I’d like to see cosplay pics, especially if somebody turns up as a pixelated Chuckie Egg! :-) |
Trevor Johnson (329) 1645 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. |
Jeffrey Lee (213) 6048 posts |
The following changes are now checked in:
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 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 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 |
Alan Robertson (52) 420 posts |
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. |
WPB (1391) 352 posts |
Great work, Jeffrey! Look forward to trying it all out! |
Chris Gransden (337) 1207 posts |
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 |
Jeffrey Lee (213) 6048 posts |
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. |
Michael Drake (88) 336 posts |
I’ve had a go with it, and it’s looking good. :)
It would look better without the drop shadow. IIRC ROL’s didn’t do the drop shadow.
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). |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13