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.

I'm currently thinking that this is how it'll work:

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 will be more or less exactly as they are in NeoLemmix, with the following differences:

• The default background in each style will be changed to Amiga blue.
• The water objects in Fire, Marble, Bubble and Rock will be changed to Lava, Blasticine, Poison and Vinewater objects respectively (but they'll still be 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.

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.

Comments and suggestions welcome.

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.

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!

It seems worth including your ruler in the next update at least for trial purposes, pending further tweaks you may wish to make in the meantime.

The old ruler will remain available as a toggleable alternative. The colour cycling will also be available as an optional extra.

By all means test your new ruler and see if it could be improved. I trust your judgement, and I find it unlikely that anybody would have any objections to at least giving your ruler a try.

Let us know what (if any) issues you find with the new design during playtesting and we'll see if we can brainstorm some solutions.

Quote from: Simon on May 27, 2025, 07:30:52 PMThe color cycling is fundamentally problematic ... there will be clashing colors in the cycle, i.e., stuff looks temporarily the same. Exactly what his design should have avoided.

Whatever colour we make the ruler, it will always clash with any tilesets in that colour.

If we make it blue (for example), any blue tileset will clash 100% of the time. The colour cycle means that tilesets of any colour will not clash 90% of the time.

So, do we want one colour to clash 100% of the time and all other colours to clash 0% of the time, or all colours to clash 10% of the time?

Anyways, it's something of a moot point tbh. It can be turned off in settings for those that don't like it (N.B. The colour-cycling ruler is only in SuperLemmix, it's not yet been implemented in NeoLemmix CE). Besides, your striped (or dotted) ruler solves the above problem, so perhaps should be the default. The colour cycling is (and always will be) an optional extra.

The default ruler probably does need to be updated.

We can provide a new default ruler alongside the old one and either ask the user to rename the images according to preference (the old one would have "_alt" appended to it in the file system) or, at a push, have a toggle for it in the F2 menu.

Simon's triangle-ended ruler is best. I'm personally not too keen on the stripe, but if others like it then sure, we can go ahead with that design. I wonder: would black & white (as opposed to rainbow) colour cycling suffice here instead?

Colour cycling would always be optional either way:

Version 2.3 update:

Several updates this time around, including updates to the OG styles, Physics and UI.

Styles

• Added additional pieces to Crystal, Dirt and Rock styles - it's now no longer necessary to use the modded versions which include these pieces

Physics

• Climbers now bypass the "oh no" phase when assigned a Bomber (so, they explode immediately)

UI Features

• Updated Debriefing (Postview) screen:
  • Moved "needed" and "rescued" onto one line
  • Added lines to show "time taken" and "skills used"
  • Changed score color to green
  • Centered all lines that can & should be centered

• Bugfix - When all levels in a group are completed, the "Congratulations" message is now shown on the last level of the group (after the previous fix, it was being shown on any level except the last)

• Skill Panel status - The 'total lems from start' count is now appended to the hatch number

• Skill Panel status - The lemming head icon now shows 'total active in level' / 'maximum possible that can still be saved'

• The current commit ID is now automatically shown on the "About" window (this may come in useful in the future for debugging purposes)

A reminder of what's new as of 2.0.

---

Get the latest version here.

Since more than 2 months have passed since the release of 1.0 and there hasn't been much in the way of feedback (and all feedback so far is either in active discussion or has been addressed/resolved), it seems appropriate to start thinking about the next version.

The main thing I'd like to focus on this time around is the replay system, beginning with the following proposed features/updates:

Animate Replay "R" icon and make it clickable to cancel the replay (including during Replay Insert mode)

Add Playback Mode - this can auto-play an entire folder of replays for a selected levelpack, with various playback options

Update Replay Renamer (now known as Replay Manager in SLX) to include additional replay renaming options (including the ability to append the pass/fail result of each replay) when performing a Mass Replay Check

Add .nxrp Windows-File-Association; when associated, clicking a replay file will open NeoLemmix and load the level & replay, ready to be played back immediately!

I'd also like to propose the following skill panel updates for 1.1:

Make negative save count optional; the alternative would be to count upwards from 0 with the number in yellow until it reaches the save requirement, at which point it would become green

Add (optional) mouseover hints to all skill panel buttons

Cap Lemming counts at '999' ('-99' for negative numbers) across the panel to avoid visual bugs when the lem count exceeds this number

That should be enough to be going on with. Please post a reply with any suggestions/questions/comments you may have. Work on this will likely be very slow compared to my usual rate, but sooner replies are always better than later ones.

Quote from: CrazyAfroAli on May 20, 2025, 08:54:06 PM(with classic mode enabled, of course).

Glad to hear it!

Playing without Classic Mode is the norm on the Forums and you'll likely switch to that eventually (as we all do!), but it's great that you're choosing to experience the game as originally intended for your first playthrough

Quote from: Simon on May 18, 2025, 11:20:32 PMBetter in what way? The click succeeds; it queues, which is what I want. Before, successful queuing played no sound, which was odd indeed. But now, the success sounds like failing, and it feels buggier than before, not better.

It's probably a matter of opinion to be honest. I think it's good that we hear the assignment audibly fail, even if it gets queued. If we have a choice between nothing and an audible fail, the latter is preferable. It's difficult to say exactly what's better about it, I suppose it just makes the game more tactile.

There may be a way to see whether the queue frame is >= 1, and if so then play a different sound as opposed to the regular fail sound (assuming we figure out a way to "know" the reason for the failed assignment).

Quote from: Simon on May 18, 2025, 11:20:32 PMIf the queue fizzles due to time-out ... well, should it ever time-out in the first place? The queued shimmer should stay in the queue until the climber is at a ceiling. If he falls/hoists, then we can clear the queue.

At present, the queue length can be customised up to a maximum of 20 frames. I guess we could make it a maximum of 100 frames if you'd prefer a longer queue time?

Quote from: Simon on May 18, 2025, 11:20:32 PMIt's conceivable to lie in the skill panel, and show fewer skills on the skill button even though they're unspent in the physics. Can't tell from the outside how elegant that would be. Can be fertile ground for bugs.

I'm 50/50 on this. On the one hand, if the game is paused at the point of assignment and we assume that the queued skill will be successfully assigned, the pre-deducted skill is more useful UI to the player. On the other, yeah this sounds like bug city. I suppose we could show the number in a different colour for the duration of the queue; if the skill doesn't get assigned, revert colour and skill count. If it does, simply update the colour to default (the skill count having already been deducted as per your suggestion). This way, there's more state tracking going on and debugging becomes easier.

Some interesting ideas here, but I still think that this particular part of the UI (i.e. skill assignment feedback) is good enough as it is. Perhaps this is one to sit with for a while and see if it comes up regularly enough to be a problem worth solving. Better and more specific ideas may come up later.