[BUG] [PLAYER] [FIXED] Framestepping has low performance

[Simon]

Status: Changes to the framestepping / state saving and loading have been implemented that should greatly improve performance; change is included in V1.39n-B update.

[Simon]

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

[Nepster]

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

I just playtested a long level for DynaLem and had to wait about 2 or 3 seconds just to go one frame back! Given that I wanted to assign some miners more or less pixel-precise with the result only visible after about 3 seconds game-time, I spend MUCH more time waiting for the timeskips to happen than actually playing.
At the end I found it easier and faster to skip about 7 minutes game-time going forward than to go a few seconds back!

[IchoTolot]

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.

[Simon]

I too find framestepping performance extremely important still. If there's time to work on any major improvement, improving framestepping will be a guaranteed hit.

I have reported the RR timing for completeness only, not because it's urgent.

-- Simon

[namida]

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

[namida]

I've started work on this. At this stage, I haven't tried it with frameskips, only with save/load states. The performance increase is noticable even in situations where it wasn't overly problematic before; I'd imagine in situations where it was noticable the improvement will be amazing. There are still some minor, purely-graphical glitches (relating to the skill bar) to sort out, and I haven't tested it in more complicated situations yet (such as with zombies/ghosts, or rising water). Probably some functional glitches I haven't yet encountered, too.

Current issues:
> Skill counts, etc are not correctly updated when loading. This can range from "until the next frame" (eg. for the time limit) to "until the value is changed" (eg. for the release rate).
> Left-facing blockers graphically shift one pixel to the right one frame after loading. (Seems to apply to any state that doesn't have different left and right facing graphics.)
> Moving background objects are not in the correct place after loading. The same is also true for rising water. (These two are almost certianly related as they're handled in a very similar way.)

[namida]

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.

[Simon]

It's great to see progress on this!

Whenever NL is running, people will devote most of their mental capacity to it. Standard applications will be running alongside, but no expensive computations. I'd find it okay if NL eats a few hundred MB of RAM in total, if you can still get noticeable speed improvements.

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 take this as a compliment for my own code. <_<; Thanks!

-- Simon

[namida]

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.

[namida]

Alright, I implemented use of these save states for backwards framesteps, and as expected - huge performance increase.

I've set it to keep save states at the following points (all time measurements are in terms of game time, not real time - ie: 1 second = 17 frames):
- Every 10 seconds during the most recent minute of gameplay
- Every 30 seconds between 1min ago and 3mins ago
- Every minute beyond that
- Frame 0 (this avoids needing to re-render the level on a restart / loading a replay)

Anything that goes backwards in frames will find the closest save that's prior to the target point, and work forwards from there, rather than from the very start of the level. At least on my machine, in practice, this results in instant loads. Using the intended solution replay for Insane 20 (which takes just shy of 9 minutes), the memory usage near the end of the level is about 150MB, which isn't too bad IMO.

I've uploaded a new experimental version that has the improved framestepping fully implemented. Let me know if you encounter any problems.

[namida]

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