Previous discussion in now-locked NL 2 topic: More responsive "frame + 1 sec backwards". The problem has been explained pretty thoroughly.

tl;dr: To go back in time, NL restarts the level and recomputes from the very beginnig. This is comparatively slow, even on a reasonably fast Windows machine. There are algorithms to improve performance.

Low-performance framestepping feels more appropriately labelled as bug than suggestion. People refrain from using framestepping for correcting larger distances. Framestepping back and forth frivolously adds to the game experience, lowers the cost of experiments during play, therefore unfolds the feature's potential fully.

Let's not sweep under the rug that NL's framestepping was the inspiration to make the feature in Lix. People became very happy once it was in.

More existing discussion:

• IRC #lix, 2016-01-13, around 16:24 UTC, between namida and me.
• Framestepping, improve performance on large steps, a github issue for D Lix. I've put in details, but this was mainly a note to myself. You (namida) have developed the basic idea yourself already; if the github issue remains unclear, ask for clarification.

-- Simon

It's not just [HIGH PRIORITY]...for me it would even go to [HIGHEST PRIORITY]!

Even though it is difficult to implement....the result (as I saw it in Lix) is worth like all of the gold in Fort Nox

I could give thousands of examples like Nepster where this would have saved me a ton of time and nerves!

This is where the saved time from the RR change suggestion would be the most useful.

Please reconsider the [LOW PRIORITY] and replace it by [HIGH PRIORITY]. I find this much more important than any changes in RR-changes!

When I decide on this, it's determined based not just on how important the change is, or how commonly requested it is, but also the difficulty of implementing. For example - this bug here, or this suggestion here, weren't very widely requested, nor were they particularly important, but they were very easy to fix/implement, hence the quick response.

With that being said, since this one seems to be in high demand, I might see if I can look into it a bit sooner than I otherwise would have...

Okay, I *think* I've sorted all the issues with the improved save / load state (which will in turn be used to improve frameskip performance - the idea being that every so often* it'll do a hidden save state, and use these as a starting point for frameskips, rather than recalculating all the way from the start of the level). I haven't yet implemented any frameskip improvements based on it; but I just uploaded an experimental player release that has the improved code for save / load state. Try it out, and let me know if you encounter any problems (especially ones that affect game physics). If it seems that there's no issues, I'll go ahead and start working on using it to improve framestepping.

Loading states, even near the end of long and complicated solutions to large levels, should now be virtually instantaneous, rather than taking up to a second in some cases. Framestepping has not been changed, so one way to test for situations where you think you've found an inconsistency is to load a state, step back one frame (which still recalculates from the beginning, as it always has), then load the state and see if it looks like you've simply advanced one frame.

* Very scientific terminology here. I haven't worked out the exact details yet, and will probably do some testing of various setups to see what's the best tradeoff between performance and memory usage. On a large level (say for example, Insane 20 "Goodbye Galaxy" from Lemmings Plus IV), a single save state can require 7MB of memory usage.

You had quite major performance problems on your laptop, right? Have you tried the experimental release, and if so - do you notice any lag when saving a state, and if so, how significant? If you could try it, and let me know (a) for an average level, let's say something like Mayhem 5 or 6; and (b) really large levels, for example most of those near the end of Lemmings Plus IV (Insane 18 or 20 is probably ideal - recent releases (all those in NXP form) have all levels unlocked by default).

Number of terrain pieces / steel areas, and actions performed so far, should have little impact (if any). The major factors that are likely to slow it down is the level being large (in terms of dimensions), and lots of lemmings having been spawned (even if some of them have died since). Number of objects will affect it to a lesser degree, but not zero impact. In this regard, Insane 20 is a good level to test, as it has a huge number of objects, 100 lemmings, and is 3 screens wide by 3 screens tall - which I believe is the largest NeoLemmix level currently out there, although I could be wrong.

I'm closing this topic now, as an official release with this implemented has been released. However - do report any bugs you find with it (by creating new topics).