Fullscreen mode does not work on Linux

[egrath]

Behavior When entering fullscreen mode with Settings->Video->Fullscreen the screen gets distorted

Expected behavior Screen gets scaled to size of full screen window in the same way as it does in the Windows version

How to reproduce Run b-em in Linux. It does not make any difference if running on X11 or Wayland; Tested it on RHEL 9 (GNOME DE)

[SteveFosdick]

I cannot get anything that looks odd with the latest master from Github, gc8edff0. I get this: But I am also running on Arch Linux. Can you confirm which version of b-em you are running and maybe attach a screen shot/photo?

[egrath]

That's (almost) exactly the way it looks on my device. But isn't fullscreen supposed to scale the graphical output to fit the entire screen?

For the "almost" part above: Will provide a screenshot soon. Essentially everything outside of the BBC's screen is visual noise in my case (looks a little bit like random binary data in the video surface buffer)

[SteveFosdick]

That's interesting. I wonder if I am remembering correctly, but I think at one time the full screen mode used to maintain something close to the 4:3 aspect ratio of a real BBC micro on an old 4:3 CRT. That means if the PC monitor is wide screen, the bitmap produced by the emulation of the BBC Micro graphics would be scaled to fit the central area of the output "window" and the rest would be filled by drawing black rectangles in the empty space.

There was a performance optimisation a little while ago, for B-Em running on Windows, to declare the Allegro window to which this is done write-only rather than read write which, I think, means there is no guarantee what is in it prior to being drawn, i.e. the whole window is expected to be drawn for each frame. Possibly, on my system the window is being set to all black in hardware and on yours it is left random.

There was also a pull request a little while back connected to full-screen so I will see if I can find what exactly that did. Looking at my own screen shot again, this is not what I would have expected. Even if it is pillar boxing rather than stretching, I would expect the BBC Micro screen to be centred horizontally.

[SteveFosdick]

I think I can see a little more of what is going on here. If I change the "border" colour to blue, In this screen shot: You can see there is a small border at the bottom. This is because, on Linux at least, the window size we have to give Allegro needs to allow for the menu but how much vertical space the menu takes up depends on the font used, which in turn depends on the user's settings, so we allow a little extra because, in that case, there should be 1:1 between the BBC micro pixels and PC pixels, or at least an integer multiple.

If I then swap to full screen: The code that is drawing the output from the BBC Micro emulation thinks the screen is smaller than it really is and is actually letter boxing it when I was expecting pillar boxing. Everything to the right of the two blue bars, or below the bottom blue bar, is undrawn space. I assume this is where the random junk appears?

[SteveFosdick]

The two pull requests: https://github.com/stardot/b-em/pull/166 and https://github.com/stardot/b-em/pull/167

[SteveFosdick]

I have created a branch for this issue and pushed a commit which I believe fixes this: https://github.com/stardot/b-em/tree/sf/issue193

[SteveFosdick]

Now updated further to make it work again on Windows.

[egrath]

Just tested it, at least the graphical glitches are gone with this commit. But there is still some odd behavior:

• When switching to fullscreen mode, the output size of the non-fullscreen window is retained. Best explained with a example:

When resizing the window to this strange rectangular appearance and then switching to fullscreen mode, it's size is retained:

Most people will assume a full screen behavior of showing a scaled (and probably aspect ratio correct) image of the actual device's framebuffer.

[SteveFosdick]

That certainly looks strange and I can see why most people wouldn't want that, but that is not what I get. Starting with a normal window: Going fullscreen I get this: So I have pushed some more changes to the issue193 branch which I hope will give a clue as to what is going on. Some of these are just extra logging, i.e. messages written to $HOME/.config/b-em/b-emlog.txt. Going fullscreen and back again I get this:

07/04/2023 18:01:31 INFO main: starting B-em v-e610abb, Allegro 5.2.8[1]
07/04/2023 18:01:31 DEBUG vidalleg: video_set_window_size, scr_x_size=704, scr_y_size=552, winsizex=704, winsizey=580
07/04/2023 18:01:31 INFO video: Loading Mode 7 font /home/fozzy/Computing/BBC/b-em/issue193/fonts/brandy.fnt 'Brandy BASIC', 16x10
07/04/2023 18:01:31 INFO hfe: init
...
07/04/2023 18:02:10 DEBUG vidalleg: entering fullscreen
07/04/2023 18:02:10 DEBUG vidalleg: resize event with fullscreen=1, x=0, y=0, width=1920, height=1053
07/04/2023 18:02:10 DEBUG vidalleg: video_fullscreen_wsize pillarbox, aspect=1.82336, scr_x_start=258, scr_y_start=0, scr_x_size=1404, scr_y_size=1053
07/04/2023 18:02:27 DEBUG vidalleg: leaving fullscreen
07/04/2023 18:02:27 DEBUG vidalleg: resize event with fullscreen=0, x=0, y=0, width=704, height=553

The most interesting bits are the presence of absence of the re-size event along with the values it provides, though the reported version of Allegro may be interesting too.

I have also added the ability to visualise different parts of the screen, like the blue border I think I posted earlier (which I had done by a temporary change to the C code). These are implemented as extensions to the VideoNuLA emulation so the code can be there without normally being activated. VideoNuLA itself sits in the I/O space used by the standard Video ULA but decode the addresses more completely so &FE22 and &FE23 are distinct from &FE20 and &FE21 respectively. &FE22 is a control register used for various purposes in which the upper four bits are a command code and the lower four bits are the value. I have grabed two unused command codes 14 (E) and 15 (F). 14 sets the colour of the border between the emulated BBC micro screen and the edge of the PC screen, i.e. when pillarboxing or letterboxing in full screen mode. 15 sets the colour used for the part of the BBC micro screen is subject to video blanking. The values, in each case, are a position in the VideoNuLA pallette.

So, some examples:

?&FE22=&E4

For me gives this in normal window mode: and this in full screen mode: Adding ?&FE22=&F3 gives: and in full screen: Could you try building the latest code on branch https://github.com/stardot/b-em/tree/sf/issue193, do a test of switching to full screen and back, then let me have a relevant portion of the log and maybe also do this with ?&FE22=&E4 and post screen shots, please?

[egrath]

Yes for sure, will let you know on Tuesday next week, be on vacation over easter holidays 😎

[egrath]

I just tested branch sf/193 and it works as expected on the same device it didn't worked previously.

Below find the b-emlog.txt file:

11/04/2023 06:02:03 DEBUG log_open: log options=77311
11/04/2023 06:02:03 INFO main: starting B-em v-b899ab3, Allegro 5.2.8[1]
11/04/2023 06:02:03 DEBUG vidalleg: video_set_window_size, scr_x_size=704, scr_y_size=552, winsizex=704, winsizey=580
11/04/2023 06:02:03 INFO video: Loading Mode 7 font /home/egon/tmp/BBC/b-em/fonts/basicsdl.fnt 'BBC BASIC for SDL', 16x10
11/04/2023 06:02:03 INFO hfe: init
11/04/2023 06:02:03 INFO model: starting emulation as model #4, BBC B w/8271+SWRAM
11/04/2023 06:02:03 DEBUG vidalleg: resize event with fullscreen=0, x=0, y=0, width=704, height=552
11/04/2023 06:02:07 DEBUG vidalleg: entering fullscreen
11/04/2023 06:02:07 DEBUG vidalleg: resize event with fullscreen=1, x=0, y=0, width=1920, height=1052
11/04/2023 06:02:07 DEBUG vidalleg: video_fullscreen_wsize pillarbox, aspect=1.8251, scr_x_start=259, scr_y_start=0, scr_x_size=1402, scr_y_size=1052
11/04/2023 06:02:11 DEBUG vidalleg: leaving fullscreen
11/04/2023 06:02:11 DEBUG vidalleg: resize event with fullscreen=0, x=0, y=0, width=704, height=552

Thank you very much for fixing this issue!