ARM BASIC: SOUND extension?

Rick observed

Yours looks quite pleasant, but perhaps ought to be a tad heavier.

The transfer curves are tunable of course.

One thing I do notice is the kerning is a mess – “Ho(space)merton”, “cu(space)stom”, etc…

I don’t have sub-pixel rendering switched on.

I don’t have sub-pixel rendering switched on.

Right, so a specific feature of the Acorn design¹ that was supposed to improve things visually, and was definitely missing from at least the first attempts on other OS’s, is turned off.
Yup, fair comparison.²
As Rick says Windows has had a lot of development work in the last 20+ years so there’s an off chance they have sub-pixel anti-aliasing turned on by default these days.

¹ That I don’t think got bundled into Windows and as I recall the story went that MS did ask Acorn (probably made up somewhere)

Is this on your TV?

Yes

Try this test

Passes with flying colours. The “lagom” screen is perfect everywhere; the purple screen is slightly darker at the bottom than elsewhere, but only very slightly; the other colours I can’t see any difference across the screen at all.

For what it’s worth, I sit with my eyes about 480mm from the screen, in the middle horizontally, and well above centre – it’s much more comfortable to have to look down a bit to see the bottom of the screen than to have to crane my neck up to see the top, so the bottom of the screen is 70mm below the surface of the desk, and the top 460mm above it. My eyes are 380mm above desk level. All complicated by the fact that the screen leans backwards a bit so the distance from my eyes to the bottom of the screen is only slightly more that the distance to the top.

Rick wished

but perhaps ought to be a tad heavier.

Tuning the transfer curve: (open this image in another tab or it’ll get squished by the forum formatting)

Tuning the convolution matrix: (again, new tab please)

Clive said

Passes with flying colours.

Great! Then I’m sure you’d tune your rendering to your liking.

Steve observed

Yup, fair comparison

SPR was switched off on both RISC OSes, so it was a fair comparison with each other.

there’s an off chance they have sub-pixel anti-aliasing turned on by default these days

Nope. That’s not how TrueType works – it hints the glyphs to the pixels. FontManager could do so if it knew anything about antialiasing, but AA is kind of bolted on afterwards.

FontManager produces a carefully hinted B&W glyph at 4× resolution, with perfectly balanced stem widths and nicely rounded adjusted curves… and then smears it into a blurry mess with SuperSample, starting stems half-way through output pixels and generally being not-very-clever.

Now it could hint to the ultimate output pixels… for example, pulling the left edges of an H onto output pixel edges. This would certainly be better vertically, as it would allow the horizontal stems to snap to actual pixels.

It would be nice to have the option anyway, as you do in Windows.

Then I’m sure you’d tune your rendering to your liking.

Probably won’t bother, actually. As I said, I don’t really have much of an issue with any of them. None are perfect, I don’t expect them to be; all are perfectly readable, even at 1:1 or indeed somewhat reduced. I’m not trying to produce high quality journals any more (used to achieve that well enough on A5000s and A540s, back in the day – good enough that Cambridge University Press’s own typographers couldn’t tell which pages their colleagues had set and which we’d set on the Acorns) and I use the Mac for all text work for my website – and really only care that it’s comfortably readable. Those badly positioned apostrophes in Times (or New Roman) Italic do annoy me, but I live with them.

I don’t have sub-pixel rendering switched on.

Does the original RISC OS sample?

Tuning the transfer curve / convolution matrix

No idea what those actually mean, but nice. You can set the sharpness and heaviness to your own personal preferences.

but AA is kind of bolted on afterwards

It developed from the original bitmap font idea?

and then smears it into a blurry mess with SuperSample

So is that the bit that needs “fixed” then? [note, nemo, I’m specifically talking about the rendering, we’ll leave the thousand other FontManager issues for another discussion!]

Of course, can it’s not like the PRM is any use here: The SuperSample module provides SWIs for the use of the Font Manager. You must not use them in your own code.

Steve observed

Yup, fair comparison

Perhaps I should have used the modern idiom with a “not” at the end. I felt you were doing fine until you specified setups with so many other possible causes of problem behaviour.

SPR was switched off on both RISC OSes, so it was a fair comparison with each other.

I wasn’t referencing the 4.x and 5.0 comparison, it was the RO vs. Windows
Plus the question of whether both RO versions were in the same emulator.

The emulator being the main point – that the whole thing could be a peculiarity of the emulator or emulators.
Hence my comments about removing possible causes of difference.

Anyway, if there’s a specific wrongness in RO5 rendering (assuming it isn’t an emulator thing), was it introduced in RO5 or did it exist in 3.7?
Where should people concentrate attention in the source?

Where should people concentrate attention in the source?

I think he’s already answered that – FontManager makes nice fonts that SuperSample then gleefully buggers up in the transition between virtual font rendering and actual screen output.

https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Video/Render/Super/s/Super?rev=4.5
(ugh, maths)

was it introduced in RO5 or did it exist in 3.7?
Where should people concentrate attention in the source?

Perhaps I should rephrase and say *when" was it introduced?

If it’s the same in RO3.7 and 4.02 then the fault change is in the RO5 fork, if it’s better in 3.7 and 4.02 then it’s a fix change in the RO4.x fork.

Important to go back to the right point in the source revisions, or forward up the right branch if you have the access.

Rick said

No idea what those actually mean, but nice

A convolution matrix is a two-dimensional array of pixel weights, which for each output pixel is multiplied against a set of input pixels, summed, and the result used as a grey value. For reasons that are now impossible to justify, every single font pixel is the sum of forty nine input pixels. Which is ridiculous. Every pixel is influenced by pixels that are up to 12 pixels apart, as a Manhattan distance. This is why it’s blurry – the radius is massive. It’s actually a 2D triangle filter.

A transfer curve is a one dimensional mapping from one input value to one output value – a gamma curve is a specific type of such a function. The original SuperSample has a convolution matrix and a simple linear scale. My version has an intermediate transfer curve to adjust the result of the convolution, as well as a user-definable matrix.

As for Steve’s “Where is the problem” – that’s a very wide question. The general problem is a complete lack of understanding of the gamma response of monitors, which means that SuperSample, ColourTrans and ChangeFSI to name but three get their maths wrong. Oh, FontManager has very inefficient alpha blending… and it’s wrong too. And SpriteOp. So it’s all wrong really, unless you’ve calibrated your system to a 1.00 gamma (me and… nobody else who’s still using RO I imagine). Then the naive maths in the above systems works ok.

The SuperSample thing specifically is very difficult to understand. RISC OS’s font antialiasing was pioneering, so perhaps they leaned on theory a bit too much. Or Acorn’s understanding of CRT limitations (they did have an anti-twitter patent didn’t they?) influenced their decision. Regardless, the blurry convolution matrix has no place in rendering for LCD. It’s quite mad.

And the fact that the same font displayed white-on-black and black-on-white looks different weights should have told them they were getting it wrong. But then we’re talking about the same Acorn that when it was flogging its DTP system said, when asked how they solved the dot-gain problem, “What’s dot gain?”. Remember that very few people were involved in the design and production of the early code, and their experience was not industry-specific.

I have a distinct memory of the tool used to create antialised fonts for Arthur, though I’ve long lost a copy. Back then, FontManager was bitmap only, and AA bitmaps were produced by a BASIC program that stroked a glyph skeleton with varying-sized ‘pen nibs’. I think that was a Wilson creation but I’m not sure. It may be that the theory behind the AA came from that. I know that Sophie’s input into SuperSample was minimal.

A convolution matrix

For a brief moment I thought you were talking about neural nets. There were lots of posts I missed apparently. I now have a vague grasp of how anti aliasing and friends works. Very interesting.

I avoided Ubuntu Linux for years because of the way it renders, or rendered fonts. No matter what I did, I could not stop them from looking like they were on a slightly out of focus CRT or an incorrectly resampled image. Debian didn’t have that issue, nor did any other variety I tried. A few days ago I discovered that I could disable anti-aliased fonts on my Pinebook, and they look as they should. It’s like a cool, refreshing breeze for my eyes. No, that would sting. I’m sure you know what I mean though. It’s crisp. No blurring, no lumps.
The point of my rambling is that anti-aliasing isn’t always the way to go.

Edit I think I’ve caught something from Rick – this is heading for War & Peace.

For reasons that are now impossible to justify, every single font pixel is the sum of forty nine input pixels. Which is ridiculous. Every pixel is influenced by pixels that are up to 12 pixels apart, as a Manhattan distance. This is why it’s blurry – the radius is massive.

Probably worked nicely on a 1980s TV and similar. What we now consider desperately low resolution was up beyond the available offerings then.
The other thing about all those calculations for the level of influence on a single pixel is the computational load.
Perhaps with a better match of the generated pixels to the display pixels and a deeper series of colour shades the ant-aliasing isn’t needed¹, or we consider this:

The original SuperSample has a convolution matrix and a simple linear scale. My version has an intermediate transfer curve to adjust the result of the convolution, as well as a user-definable matrix.

and say, source submission?

As for Steve’s “Where is the problem” – that’s a very wide question.

I tend to start wide and narrow the focus. Habit, can’t get rid of it – can’t actually see any benefit in getting rid.
When I modified my question with a rephrasing I was trying to ask the diagnostic question of where in the source (which revision more than anything) the problem lies.
Your expanded explanation, which I think some people² might understand, suggests that it was in the original Acorn code and therefore any better behaviour in RO4 would suggest a code change in that fork.

The SuperSample thing specifically is very difficult to understand. RISC OS’s font antialiasing was pioneering, so perhaps they leaned on theory a bit too much. Or Acorn’s understanding of CRT limitations (they did have an anti-twitter patent didn’t they?) influenced their decision.

Possibly also the fact that it was a small set of people and there was no great amount of peer review – difficult when there are no, or few, peers.

Regardless, the blurry convolution matrix has no place in rendering for LCD.

Which is why Windows systems had different font blurring³ setups with CRT and LCD presets, to be fine adjusted by user input (usually wrongly)

¹ Although you give a specific use case, that most general users wouldn’t have, where it does work.

No idea what those actually mean, but nice. You can set the sharpness and heaviness to your own personal preferences.

Yep, it would be cool to be able to set these parameters in Configure.Fonts.

I think I’ve caught something from Rick

:-)

Probably worked nicely on a 1980s TV and similar.

Yes, this technology was designed with CRTs in mind. Additionally, I recall that ClearType (on XP) had options to tune from RGB panels and BGR panels.

The other thing about all those calculations for the level of influence on a single pixel is the computational load.

Speed was probably also a factor. That said, I think I recall reading in the FontManager docs that above a certain point size (one of the FontMaxes), the renderer uses Draw to plot the font directly to screen – I wonder if adding some sort of smoothing to DrawFile and getting FontManager to use that might prove useful?

therefore any better behaviour in RO4 would suggest a code change in that fork.

Where was it said that RO4 was any better? I thought the comparison was RISC OS (normal), Windows, and RISC OS (nemo’s version).

to be fine adjusted by user input (usually wrongly)

I don’t know about now, but with the original ClearType it showed a number of text samples and asked you to pick the best one. One would hope that the end result would be “useful” settings. ;-)

Mention of some FontManager issues, but nothing regarding changing the rendering: http://gerph.org/riscos/ramble/graphics.html#FontManager

Interesting that he mentions the lack of Unicode support. I could have sworn the version of FontManager on my RiscPC (under 3.7) was a softload that supported some sort of Unicode, as part of a betatest of a new version of Fresco, back when Ant and Argonet were working together to enhance Fresco… I’ll have to take a look, should I ever dig out the RiscPC, turn it on, and find the battery hasn’t melted the insides…

Where was it said that RO4 was any better? I thought the comparison was RISC OS (normal), Windows, and RISC OS (nemo’s version).

True, I’d taken Nemo’s comment of " RISC OS 5 on the left, Windows in the centre, my RO4 on the right." in the post here to mean his installation of RO4 rather than his personally modified copy of RO4 which you are assuming.

Since Nemo was saying RO5 was bad I was working on the basis that he was comparing to another public release.

Either way I notice that there’s a PACE derived change that altered the way the matrix was provided and tweaked a few things which might have made things worse/different.

Mention of some FontManager issues, but nothing regarding changing the rendering: http://gerph.org/riscos/ramble/graphics.html#FontManager

Interesting item in para 8 & 9 in that ramble – do you recall all the arguments about zero page stuff and my contention that the new way highlighted old niggling errors?

Yeah, well:-

The fix was to stop FontManager dereferencing the pointer if the string length was 0.

Says Gerph. Hooray they fixed a zero page error. Then he goes on to say:

However, it is useful to have a 0 byte at address 0, to prevent applications which also assumed this from failing. The Kernel workspace was updated so that the byte at 0 was 0.

Thus allowing anything else that accesses zero page addresses in a dodgy manner (like at all) to carry on in its established wrongly coded manner instead of promoting a fix. Doh!
Just think how many of the programmes with discretely hidden bugs could have been fixed years ago if ROL had followed up on the Acorn deprecation of that behaviour.

Sometimes I feel like joining Nemo and banging my head on something solid. Then I realise it’s causing pain to the wrong person.

Edit: Then again, if they’d actually forced the issue and people had been encouraged to fix their software then Jeffrey wouldn’t have written code to give meaningful dumps when that kind of error occurs – so we got a debugging tool out of it.
Wonder if it was worth the pain everyone suffered with those obscure errors/crashes.

rather than his personally modified copy of RO4 which you are assuming.

Reasonable assumption, given his demonstrations. ;-)

to carry on in its established wrongly coded manner instead of promoting a fix.

Yeah, I choked on my tea when I got to that part. One of my cow orkers offered to pat me on the back… Need I say more?

Sometimes I feel like joining Nemo and banging my head on something solid.

There comes a time when you want to do that to ease the pain you might feel otherwise…

if they’d actually forced the issue and people had been encouraged to fix their software

Just think what the RISC OS market would be like if the RiscPC was 32 bit from the outset. The market back then was vibrant, making such a change would have been a little painful, but doable. Big things changed Arthur to RISC OS, then again 2 to 3. Why not ARM2/3 to RiscPC?

Oh well…

Wonder if it was worth the pain everyone suffered with those obscure errors/crashes.

The worst is the one that shows up when page zero accesses are faked – the software that doesn’t crash, but at some point in its execution is essentially reading gibberish from page zero due to some pointer or other not being set to anything…
The sort of quirks that are likely random, impossible to reproduce, and damn near never

Reasonable assumption, given his demonstrations. ;-)

Hey, I can move the pointer without using the mouse, send a file into a recycle using the Delete key (you need shift-delete to wipe it out instantly) or get help from a selected application directory with F1 and only one part of that involves anything other than my RO5 variant. There are other bits in the list too.

No keyboard pointer control in RO4.02, no F1 for help… therefore RO5 must be better – then someone compares raw RO5 and raw RO4.x and says WTF, I’ve been misled.
That’s where assuming gets you.

The sort of quirks that are likely random, impossible to reproduce, and damn near never

… let you finish a sentence :)

then someone compares raw RO5 and raw RO4.x and says WTF, I’ve been misled.

There’s no assumption about it – go back to the original message, look at the three screenshots, read what the example text says. It’s not vanilla RISC OS font rendering.

… let you finish a sentence :)

Sorry, unexpected page zero access. I froze, repeating the magic word “ofla” over and over.

Proper end of sentence: damn near never seen twice the same way or behaviour.

Or the utterly disheartening: it crashed, unable to reproduce.¹

¹ Really? If you need software to help with reproduction, you’re holding it wrong.

I don’t think adding random applications like an image viewer or thumbnails or a wastebin into the core OS makes much sense.

I saw an old Acorn document on 4corn or somewhere, with a “Waste” icon built into the OS, so Acorn presumably intended to add one at some point. Most platforms offer this sort of functionality without addon apps so in my opinion this does make sense.

But I also don’t want to reinvent the wheel when we have an app that already does it :)

Edit: Found it. It was part of “X.desktop” on the R140 workstation. Apparently Acorn licensed this software from another company.

I also don’t want to reinvent the wheel when we have an app that already does it :)

I should have answered Steffen when he made the comment in which he further identifies what he thinks should be in the OS and where people should use a third party application/utility:

The only “must-have” I can identify is “Selectable text in writable icons”. Everything else does not even qualify for “should-have” (apart from maybe the SysLog idea and “true numerical sort”). IMHO of course, since I don’t think adding random applications like an image viewer or thumbnails or a wastebin into the core OS makes much sense. Use PrivateEye, PhotoFilter and Transient/TrapDelete if you must.

This of course is where peoples use cases differ because I regard selectable text in writable icons as a minor issue while proper logging and a boot structure that recovers from errors (and logs them) seem to me to be essentials along with a recycle delete system.
This is possibly the difference between a programmer and a support techie used to finding errors/bugs in programs or assisting users in recovering from the errors (or their own)

Transient/TrapDelete – until Fred created TrapDelete, after much comment from me about the general lack of this feature, everyone except Select/Adjust users, was faced with manual movement of waste/trash into a “bin” and any recovery was tedious as the old directory structure for the location of the data was lost.
I had hacked a copy of Blackhole to do part of the job and R-Comp were working on something similar – I paid for a copy to support the idea but never did anything with it as I’ve had TrapDelete in use since its first iteration outside of Freds RO kit but I still believe the feature belongs in the core OS

Of course, if the source is available, there’s no reason not to put those little pet projects into the core OS, or the HardDisc extensions and Apps.

Features RISC OS needs built in (but will probably never have):

• Ability to “undelete” (it was a useful feature in DOS, but I notice that when USB media came along, the feature was quietly discarded). People make mistakes. Only last year (or was it the year before?) I accidentally wiped all of the photos on my phone. Luckily I only lost a few weeks worth – the rest were backed up. Phew.

• Ability for the operating system to recover from disc errors – while I don’t begrudge paying druck for his useful tool, it is utterly inadmissable that not only does the filing system barely have any methods of recovering from corruption, what’s there doesn’t work (CheckMap’s recovery features are fundamentally broken).

• Ability for RISC OS to cope with errors happening during boot. Ideally it should be like DOS and offer a step by step prompt as well, but the fact that the boot sequence just gives up….

Add your own entries below. Let’s see if we can make up a list of things RISC OS needs rather than “stuff Select has that would be nice if we had”. :-)

Really need a new thread for this but.

Samba v2 and v3, Ipv6, Firewall, plus all the extras from Select, then maybe just maybe all those usrs who think RO5 is outdated might just upgrade. I still prefer Select RO6 to 5 in mayway, and and fell more at home on 6 then 5, sorry but that life.