Now live!

https://www.twitch.tv/simonnaar

-- Simon

Video: Splat ruler freezes CE for 5-10 seconds (70 seconds long, 4.4 MB)

This is an excerpt from my stream 3 weeks ago. I've had already played CE for 2 hours here.

-- Simon

Forestidia saw this in 0.10.29 again.

Forestidia's report

-- 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

Do you put large water areas?

Another solution, then, is to draw only the outline of the trigger rectangle in the contrastful color. The inner area can be fully/mostly transparent.

-- Simon

All right, Sunday (in two days) at 14:00 UTC. See you!

-- 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

The answer I was hoping for was: You look into the source and see an obvious performance bug with the splat ruler within 5 minutes.

According to your testing, I doubt that the lion's share is due to Wine; it's a general issue. But I haven't investigated other than how a freshly started CE won't freeze in Wine either. Even on Turrican's Space Program 10,000 BC, yes, it still stuttered, but it wasn't frozen for seconds. All my testing in this entire thread has been with low resolution and low-quality minimap.

Before you put a warning, I'd wait until we all have researched this better. The warning would also break NL compatibility in a weak sense: NL won't scold you for making large levels, but CE would.

Do you have time on Sunday, June 15th, 14:00 UTC, to dig into the CE source together in Mumble?

-- Simon

Next stream will be Sunday, June 15th, starting 16:00 UTC.

We'll play more Level of the Year 2024 submissions. I will show geoo's two Lix levels: Just Mine, and Roots of Life. I know (part of) the solutions by heart, and therefore I myself will hold back with ideas for geoo's levels. Instead, you tell me your ideas, and I'll play like that.

There will be more NeoLemmix entries after geoo's two Lix entries.

-- Simon

What problem are you trying to solve?

Do you mean the time zone name (ET), the time zone name with DST information (EST/EDT), or the UTC offset (−05:00/−04:00)?

And of what? Of when Lix saved the replay? Or of the level's built datetime? The levels' built datetimes carry no time zone information in the levels.

The point of the replay names is to generate unique filenames. It's not tailored to match your replay to my replay. To do that, a better feature is: Generate a match ID for each started match in the server, and change the networking protocol to work with match IDs. That would also be a start to allow people to observe (or even to reconnect as an active player to) a previously started networking match that hasn't finished yet.

-- Simon

Quote from: kaywhyn on June 05, 2025, 08:07:48 PMintro movie sequence: It flickers between a black screen and showing the movie.
whether there's a fix

I can reproduce this black flicker in DOSBox version 0.74-3 on Arch Linux. I remember that I have seen this flicker for many years. The flicker makes the movie practically unwatchable.

My weak guess was to fumble in dosbox-0.74-3.conf with this setting:

[dosbox]
machine=

I've tried all values for it. Earlier settings (hercules, cga, tandy, pcjr, ega) make Lemmings 3 complain about the missing VGA card. Later settings (vgaonly, svga_s3, svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe) make Lemmings 3 run, and L3 reacts according to each card, but the flicker stays in all of these settings. I've reverted to the default svga_s3 and accepted the flicker.

Failure. And no other option sounds promising to me.

I don't know about a solution. Try the Dosbox forums, or the forums of one of its forks (Dosbox-Staging, ...).

-- 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

Another worry under the current 0.10 overtime rules:

Situation:
Player A has 10 points and 90 lix alive.
Player B has 20 points and 50 lix alive.
Player B cannot attack player A's bunker of 90 lix.

Problem:
Player A can now stall and B can't break this stalling.

Reason:
Player B can't nuke because player A has enough overtime to beat B with 100 points over 20 during the overtime when player B has no skills. Likewise, player B can't shepherd his 50 lix home because player A again can win with 100 points over 70 during the time when player B has no lix.

During stalling, neither player is clearly winning. B has more points, but A has more potential.

The first hunch is, again, to allow skill assignments after nuking/starting overtime. This gives B a method to break the stall: B can start overtime and attempt to kill A's lix on the path.

Or is the situation (player B cannot attack player A's bunker) too rare to bother?

-- Simon

"Try to do that" would then mean: You select 6 for the intended number of players, you'll have seats ABCDEF available for assigning seats to hatches/exits. In the editor, you must assign exactly one seat to each exit. When you place an exit, editor will preassign a seat to that exit; you can always change the seat assignment for that exit, but you can't leave the exit without a seat assignment. Now you place only 2 exits. You can assign A, A to the two exits and keep 5 players without exit. Or you assign D, E and keep 4 players (ABCF) without exit.

I don't know if/how Lix should reject such a map when it's selected in the multiplayer browser. Even now, it's legal to play a map without exits. Interesting design problem. In a pinch, it's okay to allow no exits, that's simplest, and it assumes that authors will see it and fix it.

Existing maps should remain loadable in that future Lix. They are in the 0.10 level file format which doesn't feature exit-to-seat assignment, therefore we need a rule for importing these levels into the new system where each exit has exactly one seat assigned to it. The obvious choice is: When we load a level, we look at the intended number of players, and we distribute the seats round-robin at level load time.

-- Simon

NL 12.14 on Ubuntu in Wine 10.0
CE 1.0.1 on Arch Linux in Wine 10.6

The splat ruler lags the entire engine as long as it's active.

Repro:

• Play different levels in NeoLemmix for 2 hours. (I believe? Some preparatory step here is necessary because I can't repro it here on a fresh program run. Or do I have to screenrecord NL? I doubt it.)
  
• Play Turrican's level Space Program 10,000 BC v1.01, it's attached. It's large and it contains many special tiles. The file alone is 400 KB.
  
• Scroll around (with right-click scrolling) to get a feel for performance without the splat ruler.
  
• Tap the key for the splat ruler.
  
• Scroll around (with right-click scrolling) to get a feel for performance with the splat ruler.
  

CE froze for several seconds. If I hold (not merely tap) the key for the splat ruler in step 4, CE froze for 10 seconds, then stuttered at 1 frame per second. It was severe in my livestream from 2025-05-28:

Video: Splat ruler freezes CE for 5-10 seconds (70 seconds long, 4.4 MB)

NL/CE return to regular performance (= less lag) after we release the key. And if we play more/different levels afterward, the ruler doesn't dent the performance anymore there, even after it had dented performance on Space Program 10,000 BC.

Backgrounds on/off seems to make no difference. Can't test again now because step 1 is hard to guess/repro. So strange that it doesen't reproduce immediately after a fresh game run. So hard to guess what's going on internally ... it's such lag, and only on Turrican's level. And why do other levels run fine afterward even with the ruler?

Quote from: Guigui on June 02, 2025, 11:43:07 PMon my machine, the ruler is a bit laggy. When I press the key it appears correctly, but it stutters when I try to move it accross the screen. To move it, I better make it disappear, then reappear again elsewhere, not very handy.
Is it just me (running NeoLemmix on Ubuntu + Wine) or all NeoLemmix users ?

-- Simon