From reading the updated description, best guess is that it's a simple case of not being able to process more than 1 keypress per physics update.

So, for instance, if the hotkey for 'Rewind 1 Frame' is Z, and the hotkey for 'Select Builder' is 5, the input (if holding the Z key as described in your example) would be something like:

zzzzzzzzzzzzzzzz5zzzzzzzz

In this example, the 5 press was registered during the repeated z presses because it happened to be pressed "first" on that particular frame (i.e. before the automatic repeated z input). Sometimes, though, the z gets through first, and we just get:

zzzzzzzzzzzzzzzzzzzzzzzzz

The only solution i can think of is to implement some sort of hotkey queue which checks for keypresses and actions them on the next possible physics update (maybe NL already does this, I'd have to check).

Possible bugs that could arise: both "z" and "5" would be added to the queue , but if the 5 is actioned on the next available update, the z would be actioned on the update after that. Result: an extra physics frame rewind, possibly unwanted.

I have to ask: how often does this come up, and is it a major issue?

2.8.8 Update

Further improvements and bugfixes. Here's the full list of updates:

Level Validation - Added a setting to toggle automatic level validation on/off when manually saving a level

Piece Browser - Added option to show name rather than type for objects (restores previous behaviour)

Bugfix - Talisman Creation - User-created Talisman titles are once again preserved when editing an existing Talisman

Bugfix - UI - The mouse wheel can now interact with dropdown lists from the start, and even if a piece is selected in the level arranger window

Bugfix - UI - Settings dialog now stays on top when active (stops it from disappearing behind the main Editor window if it's accidentally interacted with)

---

Get the latest version here.

Very strange. I'm not currently at my laptop so I can't test this immediately. Has anyone with a Windows machine noticed this?

Best guess is that it's something to do with hotkey priority, I'll take a look at it soon.

I personally like the colour cycling, but can see why it may be annoying or counterintuitive to some users. Settings could allow users to specify a colour using a hex code, I'll look into this soon.

Outline wouldn't be the best idea for water and/or OWWs because in both cases the trigger area affects whatever it overlaps, including any added terrain.

The idea of CPM is to make it clear where the triggers are, pixel by pixel. Outlining is at best asking the player to work it out instead of just showing it, and at worst could even render some trigger areas invisible (if the outline is outside the terrain piece, for example.

I'm typing this on my phone, I'll come back and add some visual examples later.

As for the colour, I see no reason not to allow users to specify whatever colour they like. I'll look into whether this is feasible.

Additionally, I think it's best to provide some clear directions for what will need to be done after the release of 2.9 with existing SuperLemmix level packs and NL-to-SLX conversions:

If you've already converted your pack from NeoLemmix to SuperLemmix - OR - If your pack was made specifically for SuperLemmix in the first place

This is relevant for all packs that have already been released, plus any existing works-in-progress.

If you've created your pack for SuperLemmix, or if you've already done the conversion (and thus corrected the water objects and exit positions), you will need to swap all orig/ohno_ styles to slx_ styles in all levels that use the OG style sets. For this, I will provide a simple purpose-built tool that can be used to do this for a full pack in seconds. This will be sorted out shortly following the release of 2.9, so you don't need to do anything yet. In the meantime, feel free to continue working on your pack as normal.

If you plan to convert a pack, but haven't done so yet

In this case, it's probably best to wait until 2.9 has been released before doing anything. Then, use the updated QuickMod tool (version 2.2, which will be released shortly following SuperLemmix 2.9) to convert your pack.

If you're playing existing packs that you've already downloaded

Ensure that you have the latest version of the SuperLemmix player, the styles, and the level pack that you're playing. I'll make sure that all existing packs have been correctly updated following 2.9. There aren't currently that many, so it should be a fairly straightforward process for everyone.

The OG styles have now been updated. Here's how it'll work as of SuperLemmix 2.9:

The SLX styles will be the "official" OG styles for SuperLemmix. It'll be expected that, when making levels for SuperLemmix, these are the styles that will be chosen for making levels in Crystal, Dirt, Fire, etc. As such, the SuperLemmix Editor will list these at the top of the styles list, and they'll simply be titled "Crystal", "Dirt", "Fire", etc in the dropdown list (although they'll be named slx_crystal, slx_dirt, slx_fire, etc in the styles folder itself).

The Orig/OhNo styles are more or less exactly as they are in NeoLemmix, with the following differences:

• The default background in each style is now Amiga blue.
• The water objects in Fire, Marble, Bubble and Rock have been changed to Lava, Blasticine, Poison and Vinewater objects respectively (but they're still titled "water" so that levels using these styles will transfer 1:1 at least visually, if not mechanically) - this is to maintain aesthetic consistency across the SuperLemmix styles, many of which have had their water objects similarly updated.
• All trap animations have been modified so that they appear as they did in the original game.

Orig/OhNo styles will no longer be supplied alongside SuperLemmix engine updates, but will be made available in the full SuperLemmix styles download and will continue to be fully supported by both Player and Editor.

When converting packs from NeoLemmix, the standard advice will still be to use the QuickMod tool, which can now update the styles to the SLX versions as well as auto-correct water objects and exit positions. However, designers will now have the choice to keep their levels in the Orig/OhNo versions of the styles, should they wish to do so. The only differences now between orig/ohno_ and slx_ is the names of the water objects and the exit positions; if a designer simply moves their pack over to SuperLemmix without editing anything, the levels will appear to be visually identical to their NeoLemmix counterpart whilst behaving as expected in the SuperLemmix context (Bubble water will be Blasticine, Fire water will be Lava, etc), so they won't actually need to do anything if they don't want to. However, for optimum SuperLemmix compatibility across Player and Editor, the QuickMod style swap should be performed.

These changes will be effective as of SuperLemmix 2.9 (ETA late August / early September).

I'll probably get the styles update sorted over the weekend; it seems like there's definitely support for the idea of the SLX versions being their own separate thing from the Orig/OhNo versions, so let's get it done.

Quote from: Simon on June 15, 2025, 03:01:04 PMVideo: Splat ruler freezes CE for 5-10 seconds (70 seconds long, 4.4 MB)

This is most likely a combination of the following factors:

1) The NLCE graphics engine is only capable of using a very limited amount of memory (I'm not sure how much), and it's simply being capped out here by the overly large level and the real-time splat ruler rendering (which we can certainly look at optimising).
2) The screen is being recorded, which will further impact NLCE performance.
3) The fact it's running via WINE probably doesn't help, but that isn't certain and is difficult to verify.

Bottom line: let's see if the splat ruler rendering can be optimised. Before reaching out to Anders (Graphics32 dev), I'd like to try drawing the splat ruler as an additional cursor item (similar to the left/right arrows for direction select) and see if that helps.

The only problem is that it's very difficult to gauge exactly how helpful this would be. I can't get the game to freeze whilst drawing the splat ruler, and the ruler's impact on rendering performance is already minimal on my machine. I wonder if there's a way to monitor FPS or something like that, so I can get some actual figures to work with.

Looking good so far in favour of re-naming the SLX versions of the OG styles. Giving this a quick bump in case anyone missed the above post and wants to vote/contribute to the discussion.

One week remains before this will be actioned. Current most likely course of action is that the styles will be renamed for SLX & Editor version 2.8.8. - this is a major update, so will be done in 2.9 instead.

I've added a poll.

I'm thinking of re-labelling the SuperLemmix versions of the OG styles (with edited water objects, exit positions, etc) as "amiga_(nameofstyle)" or "slx_(nameofstyle)" rather than keeping the "orig_" and "ohno_" author tags.

So, orig_crystal would become slx_crystal, and so on.

Reasoning:

At this point, the SuperLemmix versions are significantly different from their NeoLemmix counterparts. They feature the brighter Amiga colour scheme (a subtle difference from the DOS colour scheme, but a difference nonetheless), additional water objects and other NeoLemmix-incompatible items, and updated exit positions. I'd also like to be able to modify these styles further going forward without the concern of cross-compatibility.

It would also mean that the NeoLemmix OG styles (orig_crystal, ohno_bubble, etc) could simply exist in SuperLemmix exactly as they are in NeoLemmix, which would make porting levels from NeoLemmix much easier.

Note: it would still be possible to change the level's style to its SuperLemmix variant, should the level designer wish to do so for aesthetic/mechanical purposes. It would be a simple case of swapping the style of each piece from "orig_" to "slx_": this functionality would of course be added to the SLX QuickMod tool, and could even be added to the Editor itself for quick, single-click, on-the-fly style switching (it occurs to me that this should probably be a thing anyway, since the Editor supports both engines).

Designers who have already ported their levels from NeoLemmix to SuperLemmix (and thus made the necessary cross-compatibility tweaks) would be fully supported as much as possible if this change were to go ahead; I'd be prepared to personally help make the necessary corrections to each affected pack, and I'm sure Eric (who caretakes most of the "unofficial" conversions) wouldn't mind helping with this also, particularly since much of it can be automated anyway.

Note also that, if porting levels made in the SuperLemmix OG style variants to NeoLemmix, it would still be necessary to make the compatibility tweaks (exit positions, water objects, etc). The SLX QuickMod tool already takes care of this, but - as stated - I'll most likely add something to the Editor that can quickly make the necessary tweaks as well.

Nothing will change as yet; I'll run the poll for 14 days to get an idea of people's thoughts on this, and I'll also keep in close contact with Eric regarding this, as he's likely to be the user most affected by the proposed update at this point.

If it's decided that this will go ahead, I'll likely get it sorted within a few days of the poll closing to minimise impact going forward, and include the changes in the next SuperLemmix / SLX Editor update. I'm currently about 60/40 on it in favour of "yes", but I'll let it brew for the full 14 days and see if I still think it's worth it, or if there's an even better solution.

In the meantime, leave a vote on the poll, and post any comments or suggestions you might have. Thanks 

It would almost be better to incorporate the splat ruler into the cursor somehow, in the same way that arrows can be displayed for direction select. The only issue there is that the cursor is resizable.

Sure, we can look at the source together. If we can find anything obvious, let's fix it. I'll add the suggested meet up time to my calendar, see you then

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!).

Same here, I'd be happy to check out this game. Thanks!