Other monitor turns off, terrain turns black

[Silken Healer]

Lix version: 0.10.31 64-bit (not the compile yourself version)
Operating System version: Windows 10 LTSC 2021 64-bit English-United Kingdom, Version 21H2 OS Build 19044.5854
Description: Recently, I was playing a two-player multi-player Lix netplay session with Simon from IRC. Whilst I was playing, I noticed one of my other monitors had a "this monitor hasn't had any activity, powering off soon, press OK to cancel"-type messages. The way I was sitting, it's a bit delicate to get up and get the TV remote to turn it off, so I decided to just let it power off, as I wasn't using it. After doing so, the terrain on Lix turned black. Also, I had two Lix windows open, I also had a second, windowed "neutrals" Lix instance, which this also applies too. I've also attached the replay to the post. After loading the next round, everything was fine agian.
Steps to reproduce:
I haven't tested if it's reproducible yet, but I suppose you should just

• Have a multi-monitor configuration
• Open Lix and load a level
• Turn one of your other monitors off
• The terrain should change black

Screenshots/Recordings:
Luckily, I like to record my Lix sessions from IRC with Simon to look back one, so I was recording this all, I will add a recording later once I figure out how to use FFMPEG to trim a recording based on two timestamps without re-encoding it, but for now, here is a screenshot.

[Simon]

Thanks for the report!

Lix is on monitor A, monitor B turns off, terrain in Lix (still on monitor A) becomes black. Yeah, I should investigate together with those other monitor bugs that you filed in 2025.

-- Simon

[Silken Healer]

Ah so terrain was what differentiated what turned black and didn't, I'll change the title and post to reflect that.

[Simon]

These monitor bugs -- wonder why nobody has run into them before, and you found 3 or 4 of them already this year. And you're not even using Windows 11, which is nowadays's easy blame target.

This one is particularly astounding. The already-loaded sprites, exits, hatches, ... all remain intact. Only the terrain layer becomes black or transparent, even though it's a VRAM bitmap like any other sprite/exit/hatch. Or is it? I should research. But then new terrain (the later-built staircases) can be painted onto the black/transparent as if nothing were out of the ordinary.

The terrain VRAM bitmap may be large (it's a single piece, 1:1 the size of the level), but the spritesheet is also large at 913 x 946, about the same order of magnitude as that map. That would rule out size.

No idea, must reproduce from first principles. And first find a multi-monitor setup.

-- Simon

[Silken Healer]

I think you can simulate a multi-monitor setup in virtual machines if you don't personally use a multi-monitor setup already and it would cost more time/money then is worth to get one to test this bug e.g. if you don't just have a spare TV you can plug in to your computer or something.

[Forestidia86]

I tested a bit (Lix 0.10.29 - release build - win64 - Allegro 5.2.10):

• Monitor no. 2 is set as primary monitor.
  
• Before play, go to Windows's monitor/display settings, and choose: Extend the display to all screens.
  
• Start Lix.
  
• Observe how Lix starts on monitor no. 2 in software fullscreen.
  
• Start a level and play.
  
• During play, go to Windows's monitor/display settings, and choose: Display to only monitor no. 2.
  

Either:

Out of VRAM error:
193.41 src\basics\alleg5.d:26:
193.41 Out of video memory. Can't create bitmap of size 913x946 with flags 5120.

Or:

Graphics stutter for 0.5 seconds or 1 second. After that, Lix continues to run smoothly without further stutter. But if there was terrain modification in that 1 second of stutter, e.g., a builder was building, then the newly built bridge slap is not drawn, and will continue to be invisible throughout the future:

[Simon]

Thanks!

I have to investigate whether we draw from current state onto the new savestate (that we allocate), or if the current state becomes the savestate (and we allocate a new current state), drawing from savestate onto current state.

This can merge all of the following 3 phenomena,

(a) missing bridge slap during stutter,
(b) all terrain becomes black,
(c) failed VRAM allocation,

... into a consistent world-view: The theory will be: When a monitor turns off, something happens with Lix's window behind the scenes, all VRAM drawing during this short time has no effect (but won't crash), and all VRAM allocations with this window in this short time fail (and crash because Lix chooses to crash then). In case (a), Lix wants to draw only a brick, but in case (b), Lix wants to load an old savestate including all of its saved terrain.

Leftover consistency problem: Why does the terrain in case (b) become black ... it should remain the terrain from before loading the savestate, then, right? Details, details.

In any case, more to investigate.

All of this has given me ideas to ask directly in the Allegro IRC: How does an Allegro 5 window react to monitor turn-off, such stutter etc., and should the usercode (Lix) react or should Allegro react.

-- Simon