https://u.pcloud.link/publink/show?code=XZng3j5Zmjvy5pvxrKyxrWgE2q0VlpDg89dX

Here's another updated version of my Portable Lemmings 3 game.

This is much larger, 450MB. But it's a more recent version, 1.53 instead of 1.48 and this one mounts and plays CD audio and still saves properly to the hard drive. I also included the Gravis Ultrasound drivers installed in case you want to change the audio to GUS in the settings. I found this version of the game after talking with the youtube uploader that showed the game playing properly.

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.

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

Let's keep the default as simple as possible; a simple stick with triangles at each end is the best design IMO. Anything more complex than that is likely to cause similar problems to the current Status Quo that we're aiming to replace.

Besides, rulers can be custom-created and used in place of the default anyway. People are always welcome to create their own rulers and share them on the Forums in the graphics sharing topic, which I'm happy to sticky to bring more attention to it.

The next update will feature Simon's ruler as the default, and the old ruler as an option.

Finally got around to testing this on Windows. I can't get CE to outright freeze, but on larger levels (such as Turrican's, which are massive) there is noticeable lag when using the splat ruler, especially in hi-res. In my personal opinion, it's not that much of an issue; it's comparable to the lag experienced when running enormous levels on NL/CE in general. It may be much worse on Wine, but I have no way to test this and I'm unsure as to why it would be significantly different in that setup.

My instinct here is to simply display a warning to users when a level is above a certain size or uses more than a certain amount of animated resources. It doesn't fix the behaviour, but would likely discourage level designers from making levels that are big enough (or busy enough) to end up triggering the warning.

Ultimately, NL/CE is limited by its 32 bit graphics engine. It's not something I'd be interested in updating without signifcant help from another developer, as I imagine it would involve extensive re-writes to a lot of the rendering code. We'd almost be better off creating a new engine that can handle higher resolution sprites and levels if that's what people want. Something like a PS2 Lemmings clone with an emphasis on graphical fidelity from the getgo would be better for supporting larger and more graphics-intensive levels. As it is, NL/CE just simply isn't set up for that sort of thing.

I realise that might not be the answer people were hoping for, but it's something I too have had to accept about the engine during my own adventures with it. SuperLemmix pushes the graphical capabilities to the absolute limit, and I've had to reign in a lot of my own ideas to keep them workable.

So... go low res & low quality minimap when running larger levels, and perhaps avoid them altogether on Wine if they're causing the program to freeze. I'm happy to put in a warning so that players know that the level they're about to play is above and beyond the recommended graphical limits; that's really the best I can do without rewriting the entire engine (which isn't going to happen!).

Quote from: Silken Healer on June 11, 2025, 06:31:08 PMHmmm yeah maybe that's fair; I wouldn't want the time zones to be normalized to UTC because then that would create confusion about timestamps before this potential update was added; I'd rather just keep things they way they are then that. Perhaps the time timezone could instead be added in someway to the markup of the replay files themselves instead?

Adding it as a comment in the replay data itself (and perhaps even the time itself could be added there, as filenames can easily end up changed - of course so can the content of files, but modifying the timestamp in a file would be a specific intentional act, whereas doing so in a filename could just be a "I don't care if it's there or not" thing) seems much more reasonable than adding it to the filename, if there is a desire to tag replays with their creation time.

Quote from: Simon on June 12, 2025, 02:44:08 AMWhat problem are you trying to solve?

No problem, I just thought it might be cool

Quote from: Simon on June 12, 2025, 02:44:08 AMDo you mean the time zone name (ET), the time zone name with DST information (EST/EDT), or the UTC offset (−05:00/−04:00)?

Probably UTC offset would be the most clear out of those

Quote from: Simon on June 12, 2025, 02:44:08 AMAnd 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.

When Lix saved the replay

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