Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Framestepping, improve performance on large steps #26
How to repro: Framestep backwards. The game will use the close-by saved states to recalculate. At some time, there will not be a nice close-by state. The game will load an old state, recalculate, and save finer-grained, more close-by, states, along the way. This takes some time, and produces a visible pause on my 9-year-old laptop.
Problem: Many of these states will be tossed right during the very same long recalculation. If we save every 10 frames a state that, with hope, is close-by, we don't have to save this 25 times when recalculating from the 250-frame-old step. Only the last two 10-frame-old states will end up in the state mangager.
Possible solution: In the updating logic, keep info about what state ultimately to end up at. Pass that to the savestate manager along with the current update proposal.
Framestepping is important!
Implemented the possible solution from the OP as-is. Over 100 % speed increase on longer framestepping computations (recalculations from a rather old savestate). No noticeable slowdown for short compatations. The number of saves generated seems to be optimal in theory for this model (several pairs of states, the two states in a pair leapfrog each other).
Any type of debugging or profiling slows down longer computations noticeably, which is expected, because these computations are the most expensive in the entire program.
In D, classes are reference types and structs are value types. Savestates consist of many, many of the following:
This can be expensive to copy. Making or loading a savestate may mean that about 100 to 2000 objects will be new'd on the garbage-collected heap. It's a bit tricky to convert both to value types, and placement-new doesn't bode well with polymorphism as-is.
Would love to do savestating by memmoving a few large chunks instead of new'ing 2000 objects.