Currently off-screen garbage panels are stored with the full level of detail and the same is true for rollback data.
This can lead to significant memory allocations when players chain-tennis to chain lengths beyond x1000.
Based on the pessimistic pooling strategy for rollback memory that is meant to prevent negative performance effects from rollback, when this happens online or in a replay, all the memory allocated for rollback is fed back into the pool which can make PA take (relatively) big amounts of memory: orangetriangle reported near 4GB after watching a replay with a x1264 chain.
The memory lingering after is not even so terrible but it indicates that on weaker machines with little RAM the game could simply run out of memory and start hitting the swap which would likely result in an unplayable experience. Which - again - should only be relevant for online play as rollback isn't active in local play.
A solution could make it so that regular panel updates only run to stack height + 4 and extra lines of off-screen chain garbage beyond that are expressed as only an integer. The corresponding panels would need to be generated whenever the top row is full with empty panels with the propagatesFalling flag after panels have been updated for that frame.
The field for storing the omitted off-screen garbage would need to be added to rollback data.
Currently off-screen garbage panels are stored with the full level of detail and the same is true for rollback data.
This can lead to significant memory allocations when players chain-tennis to chain lengths beyond x1000.
Based on the pessimistic pooling strategy for rollback memory that is meant to prevent negative performance effects from rollback, when this happens online or in a replay, all the memory allocated for rollback is fed back into the pool which can make PA take (relatively) big amounts of memory: orangetriangle reported near 4GB after watching a replay with a x1264 chain.
The memory lingering after is not even so terrible but it indicates that on weaker machines with little RAM the game could simply run out of memory and start hitting the swap which would likely result in an unplayable experience. Which - again - should only be relevant for online play as rollback isn't active in local play.
A solution could make it so that regular panel updates only run to stack height + 4 and extra lines of off-screen chain garbage beyond that are expressed as only an integer. The corresponding panels would need to be generated whenever the top row is full with empty panels with the
propagatesFallingflag after panels have been updated for that frame.The field for storing the omitted off-screen garbage would need to be added to rollback data.