2.00 More responsive "frame + 1 sec backwards".

[IchoTolot]

Edit Simon: Continuation topic of this issue, because the NL 2 forum is now locked.

You all know the struggle!
You play a slightly longer level and you positioned a miner wrong at the end (+ forgot to make a savestate). The frame and 1sec backwards option needs  ~ a sec to load at that time and you need many of them, so you have to wait.........

Simon has shown me this option in Lix and it hasn't these problems there!
The game makes an intern savestate ~ every minute. So when you go a sec backwards it needs to replay < 1 minute to do this -----> even in a 15min+ level (we tested it on my comp) the frame + 1sec backwards options happens nearly instant!

So I think this would be a big improvement of the basic features and gameplay in 2.00!

[namida]

The main issue here is a tradeoff between "time to render / update physics each frame" (as well as memory usage) and "time taken during a backwards skip". The current code replays (without updating the screen) from the beginning until the target point, which is indeed quite inefficient. How to improve on this is another question; and certianly one that I'll be thinking about more once I'm up to implementing physics for V2.00n. An option similar to what you describe Lix doing is indeed a possibility I had thought about.

[Simon]

The exact Lix algo is slightly different from what Icho describes; the fundamental idea is correct. The performance improvement is huge.

There are three pairs of savestates. Savestates are complete snapshots, not pointers into the replay as in NL. In each pair, for a fixed c, one savestate is taken every 2n * c physics updates, the other is taken every (2n + 1) * c physics updates. The first pair has c = 10, the second c = 50, the third c = 200. These values were chosen to combat networking lag. The pair for 200 updates catches even unplayable lags of over 10 seconds.

In singleplayer, this makes for a performance hit once in a while, after you have gone back so many times to exhaust all pairs. The resulting pause is comparable to longer than what you have in NL. While computing that long, the pairs are overwritten all the time again. This makes additional backstepping extremely fast, even after the single performance hit.

The values for c are chosen for networking, they are not optimal for singleplayer, and produce the above-mentioned work spike. It can be leveraged slightly with a fourth pair at c = 1000 or higher, which would correspond to saving less than once per minute.

-- Simon

[namida]

Why save 2n and 2n+1? I don't see any advantage of such, unless the user happens to want to backstep at 2n+2. Would it not make more sense just to save a single savestate at n? Or is that primarily for network play?

[Simon]

The idea was that incoming networking packets force a recalculation of around 2 to 5 frames. Assume I save every n-th update and discard the state for n - 1 at that time. It might be that the latest n-th save is too young, and an older savestate is called for.

And it guarantees other meaningful older states even when n₀, n₁, n₂ reach their least common multiple.

It has never been performance-tested scientifically though. You can probably improve on this idea. Maybe singleplayer shouldn't throw all old states.

-- Simon

[namida]

I'm wondering if it might be a better option (perhaps actually make it an /option/, under an "Advanced" tab or something since the average player might have no idea what it even means) to mostly use a system based on snapshots triggered by various actions, rather than nessecerially by time (although a backup one based on time every 30secs or so might still be appropriate).

Pausing would be one very good action to use - not nessecerially because a pause always indicates an upcoming action that might need to be reversed (although there's no denying that it often will), but because this is one of the times when any performance impact will be least noticable.

[Simon]

Making deep savestates shouldn't be too expensive during normal play with graphics. Maybe look up how much RAM & VRAM is eaten by a savestate, that might be worthwhile to keep low in total, don't bunker too many savestates.

Making deep savestates every 10 frames is expensive when you're computing physics as fast as possible, and don't have to display graphics in between the single updates. Unneeded deep savestates were responsible for 80 % of computing time per level in the noninteractive replay checker.

Anyway, experiment, and maybe profile. If you find something smart, more power to you.

-- Simon