I don't see why anyting would need much extrta RAM usage either. Maybe I'm missing something, but all entities that have data changing over time (e.g. position, animation frame) will already have a current position (frame, x/y, etc), and a delta (animation speed, velicity x/y, etc) that are applied each update. Unless the deltas are calculated based on other properties each update?SyncViews wrote:As for memory, "Additionally storing all of this information twice would increase RAM usage",You do not store the entire object twice, most of the object state is either not rendered or interpolation would have little to no benefit
From FFF-150, it seems that a "prepare" step happens between updates, before rendering a frame. I assume this must make a copy of the entity position data for things on (or near to) the screen display area, for the render phase to happen in parallel with the next update. If this prepare step not only copies the current position, but also the velicity data, then that allows for intermediate frames to be rendered, right?
And, IMHO, not everything would need such intermediate frame interpolation to give a smooth 60FPS+ appearance with a 30FPS update. Start with the basics - player (i.e. camera) movement, then tackle fast moving things (trains + other vehicles, bots), then try belts next as they're fast moving too. Some things change slowly enough that no interpolation is needed - e.g. fluid levels, and many entity animations - but if they're easy then do them too.
At each stage during this process the game remains playable. Evaluate the state after each interpolation step is added, and decide on the next thing to tackle.
Tell me if I've completely overlooked something about how things work that makes this impractical.