Big Mode on ARMBook (aka ARMBok) - developers please check your software

That sounds super, Chris.

As for 8 bit masks, well, PNG images seem to becoming extremely common/standard in terms of high quality bitmap files, and any PNG mask is 8bit. As such, it is very common to come across images with shadows and the like implemented with 8bit masks that just look horrendous without. But as you say, it’s not a simple job.

I was in the process of putting out updated versions of several of my apps. However, I have now put that on hold to check that all is aok for 180dpi display modes, and to produce reworked 180 dpi sprites as needed.

Some questions come to mind. When an app launches, the appropriate sprite files are loaded (sprites, sprites22, spritesXY). What happens if you now switch from say a 90dpi mode to a 180dpi mode? Presumably the wimp continues to use the 90 dpi sprites, and do scaling as necessary. I can see how it would be possible for the correct version of system ROM sprites to be used, but not for sprites in files spread out over all the apps.

I am not sure how it would behave for some of the possible transformations (eg colour depth).

I have tried a few simple things. Changing the colour depth, for example, from 4bpp to 8bpp is fine – the mask is preserved.

In most cases, the OS automatically pixel-doubles so that 90dpi sprites work without issue. The high dpi sprites should be called (!)Sprites11 by the way (as opposed to (!)Sprites and (!)Sprites22 that are commonly included) – I’m sure you know, but I’m including that info for other readers of this thread.

Occasionally you find apps plotting their own images without scaling, but that tends to be very specific, manual plotting. The only thing that I noticed might be affected during a quick test of the disk image today was !PrivatEye which has an orientation icon in its “rotation” window that looked a wee bit undersized. Didn’t affect the functionality.

I have noticed that !BubbleHlp fails miserably on EX0 EY0 modes unless you start it before selecting EX0 EY0.

I think it already does; I just need to make sure (my RISC OS machine is currently packed away as I’ve had a guest here for a week and needed the desk). To be honest, I think the most major issue I’m going to have is lack of 68×68 icons :)

I can now confirm that all 1 of my released GUI apps are happy with EX0/EY0 modes, including the icons (I must’ve been thinking ahead at the time!). NetSurf is a bit unhappy (weird rendering glitches) and I also noticed an oddity in the OS itself with the mouse cursor; if I boot up in 0 then change to 1, I end up with a quarter-sized cursor.

NetSurf is a bit unhappy (weird rendering glitches)

To be honest, I’m surprised that it works at all. When I last looked at the RISC OS source, it was very hard-coded to the idea that 1 pixel = 2 OS Units. ISTR giving some thought to fixing this, and concluding that it was going to be a lot of work to sort out.

The only page I tried was the help file that comes with Seasonal, which is more-or-less just plain text. I dare not try something more complicated after reading your post :)

After Andrew mentioned to me at the RISC OS Experience that StrongED had issues with ex0/ey0 modes I’ve looking into this.

StrongED

The latest alpha release seems to be okay when using bitmap or outline fonts. There are issues when using the system font, in part because of assumptions that don’t hold in ex0/ey0. Right now I’m finalising changes to the VDU redraw code that fix these issues.

The only remaining ‘issue’ is that bitmap fonts don’t look bigger in ex0/ey0. This is because the pixels are written directly to the screen and so are unaffected by changes in the eigen-values. The same is true for ZapRedraw.

A simple, but manual, solution is to create a bigger bitmap font. I did a quick conversion of a 8×16 bitmap to a 16×32 one and that worked fine.

Zap

Bitmap fonts seem to be fine with Rick-05 but system font is problematic. The OS uses 16×32 characters but ZapRedraw seems to treat them like 8×16. Perhaps the fixes made to bitmap fonts need to be applied to system font too.

Another issue I found is that Zap seems to be more susceptible to redraw glitches with the iMX6 hardware acceleration than other applications. It shows up particularly when dragging windows diagonally downwards across a Zap window. This not limited to ex0/ey0 modes BTW.

Observations

Whilst investigating StrongED’s redraw issues I found an number of other oddities in ex0/ey0.

Pressing F12 does not scroll up the screen to make room for the command line at the bottom. Instead the prompt appears several lines down from top of screen and printed over the backdrop.

Running a simple BASIC program that outputs some text doesn’t cause a command window to appear but the whole screen is cleared and the printed text is displayed in the top left corner.

Certain toolbox gadgets (textarea, scrolllist) don’t update correctly when changing to/from ex0/ey0. The font used isn’t adjusted so text is either too big or too small.

So it looks like the OS needs some updating for ex0/ey0 too.

If we’re doing OS oddities as well:

On the Raspberry Pi, the bottom edge of the pointer is missing in EX0 EY0 modes. This isn’t too bad when it’s the usual (arrow) shape, but when it changes to a caret shape (e.g. over an input field) the lack of a bottom edge is more noticeable.

Incidentally, I think Fred’s F12 issue may be hardware-specific. F12 behaves itself on both the Raspberry Pi and RPCEmu in EX0 EY0 modes.

I can’t replicate the F12 or BASIC issues on my Pi 3.

The pointer issue doesn’t happen if I boot up in EX0/EY0 mode, but it does if I boot in 1/1 and then switch to 0/0. I suspect it’s the same root issue that I reported above where I end up with a tiny pointer if I boot in 0/0 and switch to 1/1.

The pointer issue doesn’t happen if I boot up in EX0/EY0 mode, but it does if I boot in 1/1 and then switch to 0/0.

Or iconsprites the relevant Themes Sprites11.

Incidentally, I think Fred’s F12 issue may be hardware-specific. F12 behaves itself on both the Raspberry Pi and RPCEmu in EX0 EY0 modes.

ISTR having this issue also on ARMX6 in non-ex0/ey0 modes like plain 4K. I don’t remember if it also happened on the RPi. However, my ARMX6 runs on an oldish version of RISC OS, which I always wanted to upgrade to the latest version before reporting the problem to Andrew, and I don’t use plain F12 much so I am not reminded often enough about this problem.

ISTR having this issue also on ARMX6 in non-ex0/ey0 modes like plain 4K.

Yes, after Stuart and Chris reported not having the issue I did some more testing. In 4k mode the issue occurs with both ex0/ey0 and ex1/ey1, 2560×1440 is okay. This is on a newly acquired Mini.m with RO 5.27 (1 Feb 2019).

So the issue is linked to resolution and not eigen-value, apologies for any confusion caused.

I don’t use plain F12 much

Normally I don’t either but when testing if StrongED’s vdu redraw was fixed I needed to do screen refreshes regularly so F12,Return was used quite often.

I needed to do screen refreshes regularly so F12,Return was used quite often.

I’ve never looked in the Wimp code for the redraw, but the redraw in the Filer was easy enough to find and use for an F5 refresh key shortcut. Might be a quick feature “win”.

F12 appearing at the top of the display embedded in the desktop.

In 4k mode the issue occurs with both ex0/ey0 and ex1/ey1, 2560×1440 is okay. This is on a newly acquired Mini.m with RO 5.27 (1 Feb 2019).

This occurs here with a Raspberry Pi 3B+ hitched up to a Sony 4k TV at 3840 × 2160, 24Hz. OS5.27 (23-Apr-19).

Pressing F12 does not scroll up the screen to make room for the command line at the bottom. Instead the prompt appears several lines down from top of screen and printed over the backdrop.

It wouldn’t surprise me if that’s caused by VDU text coordinate/window size limit

2160 scanlines is 270 rows of text, masking that with 255 could result in the bottom of the text window being only 14 rows from the top of the screen? (I don’t have a 4K monitor to try it on, so I’m not sure how close to the top of the screen we’re talking about for this problem)

Running a simple BASIC program that outputs some text doesn’t cause a command window to appear but the whole screen is cleared and the printed text is displayed in the top left corner.

Same as the above, most likely – the text window will cross the 2048 pixel (256 character) boundary on the X axis, preventing it from being set up correctly.

2160 scanlines is 270 rows of text, masking that with 255 could result in the bottom of the text window being only 14 rows from the top of the screen?

It is 14 lines down from the top of the screen.

P.S. Screenshot

caused by VDU text coordinate/window size limit

And the first comment is the amusingly predictable nemo: I have a module that…

But yes, the point still stands that a lot of the VDU behaviour is dealt with by spitting byte values directly to the VDU driver. Something that was “not a big deal” back in the days of MODE 12 and MODE 21, but falls down when it comes to 4K modes and the like.
Sadly, as nemo says, a lot of things would need to be changed in order to get larger values working correctly.

As a naff hack, why not just prefix the shellcli message with <12> ? ;-)

Running a simple BASIC program that outputs some text doesn’t cause a command window to appear but the whole screen is cleared and the printed text is displayed in the top left corner.

Same as the above, most likely

Isn’t that something that non-Wimp basic programs etc have always done? – chuck any output to the screen starting top left and not opening a window for it to be in.

It was certainly one of the reasons for me not using a background image or pattern as the plain background was easier to read the results of my mistakes. Well, some of them anyway.

2160 scanlines is 270 rows of text, masking that with 255 could result in the bottom of the text window being only 14 rows from the top of the screen

most likely – the text window will cross the 2048 pixel (256 character) boundary on the X axis, preventing it from being set up correctly

As a test a 2048 × 2048 mode does evade both issues.

If anyone is bothered by the nasty Organizer digital clock icon when using EX0/EY0, please email me at the technical support address in the Help file, and I can supply a small fix for the latest version v2.28a. Fixes for older versions may be possible.

Rick regretted

Sadly, as nemo says, a lot of things would need to be changed in order to get larger values working correctly.

I do have a module which retrofits it on-screen, yes. The “lots of things” that would also need to be updated would be printer drivers, and probably some TaskWindow hosts like Zap.

In reply to Rick

I do have a module which retrofits it on-screen, yes. The “lots of things” that would also need to be updated would be printer drivers, and probably some TaskWindow hosts like Zap.

Perhaps if Rick and other interested developers had a copy of that module to test the required updates?
Then the rest of us can pester you to make it a merged portion of RO, hopefully in a format that sits happily on earlier releases and other forks.

Perhaps if Rick and other interested developers had a copy of that module to test the required updates?

Oh yes. Here is my proof of concept VDULarge which may or may not be useful. There is a readme in the zip. It implements some SWIs that allow you to use text coordinates larger than 8bit and graphics coordinates larger than 16bit. However, it is not the full solution.

The full solution is called VDUExtend but I haven’t made that multi-OS compatible yet. VDUExtend reimplements OS_Plot to remove its 16bit limitation and provide an API for an extended-coordinate way of setting text and graphic windows, setting the origin and positioning the cursor. But you can’t have it now.

To be clear: What this module allows you to do is drive the VDU code beyond its intended coordinate limits… that may or may not work depending on the code you’re exercising. It doesn’t allow you to implement support for the new API, because it isn’t the right API. Good for testing the VDU code though. It worked on RO5 last time I checked.