[FEAT] Rewind button / hotkey

[WillLem]

Assuming your observations still apply to your recent versions, I expect the biggest gains from:

• (biggest gain) Find the conceptual difference between the one-shot n-tick rewind and rewind mode. Without looking at your codebase, I imagine that it's best for rewind mode to be implemented in terms of the (backend of the) one-shot rewind-n-ticks technology.

Since implementing Rewind as a game speed, some of the refactoring has Rewind behave (exactly) like Pause, rather than using Pause separately to prevent physics updates. This already seems to have boosted performance, but there is more to be gained.

The actual rewind mechanism is 1:1 identical to a normal backskip; the exact same method is called (GameWindow line 583 in the linked commit). The repeated keypress is simulated using a TTimer event, which seems a stable enough solution (especially compared to some of the other methods I tried).

I tested the actual repeat keypress again on a level with lots of objects and lots of skill actions; it's actually not that much better than the Rewind mode - there is still some drag now and again when there is a lot of drawing happening.

(also big) Savestate more often.

I'm going to try this, but I need to figure out how to do it first.

[namida]

Yeah, NL could be making save states far more often. I was worried about the performance impact of doing them regularly when I implemented them. I never specifically tested the "is making more of them alright" angle; only the "does it give good enough results for backstepping".

Compression would make them less performant, which is a concern if they're being taken regularly. On the flipside though, regular save states - unless they're getting overwritten / discarded very frequently too (which may not be a bad idea) - will take up more memory. How well they'll compress is a concern too - it's likely only the physics maps and the visual terrain map that are actually worth compressing. The physics maps at least should compress very well. I don't know how necessary compression really is in NL's (or forks thereof) case, but if you did want to go down that road, it may also be worth looking into whether compression can be handled in a seperate thread.

The other thing I'd raise is that a very good idea is for the game's active state to also be a "saved state". NeoLemmix doesn't use such an approach because rewinding (and in turn, save states) were a later addition there; but in the case of Loap, which was built with this facility in mind from day one, the game's current state that gets updated by the engine each iteration, etc, is also an instance of the SavedState class (or whatever I named it). This helps to ensure that everything that needs to be part of the state, is part of it.