Most efficient way to roll back data. To turn back time - c++

Question

So, I have a 3d platformer. And I want to have a button that if you hold it it makes you "go back in time". Thankfully the game is rather simple and only has one entity so the only thing that would have to be saved for each frame is.
struct Coord {
float x;
float y;
float z;
}
structure Bool6 {
bool front;
bool back;
bool left;
bool right;
bool top;
bool bottom;
}
struct Player {
Coord Pos;
Coord Vel;
Bool6 Col;
}
But I fear that is a lot of data especially since my game theoretically runs somewhere around 60fps and it would be good to have 5 seconds or so (300 frames) of data saved that can be accessed when roll-backed. I have considered each frame doing something like this
Player Data[300];
for (int i = 299; i > 0; i--)
{
Data[i] = Data[(i-1)];
}
Data[0] = "THIS FRAMES DATA";
However that sounds like it means an outrageous amount of processing power is going just in storing each frame.
Is their a more efficient way to store this data keeping all of the data in order?
Also is their a way I can tell an array slot that it has nothing? So that their arent problems if the player tries to rollback before all of the array slots are filled or after rolling back? I believe in C# i would have set it equal to NULL... but that doesn't work in c++ probably because im using structures.
Thanks much!

Answer 1

However that sounds like it means an outrageous amount of processing power
Before making such a statement it can be useful to do the math. It seems the data you are concerned with is about 40 bytes, so 40*300 = 12 kB. This can easily fit in memory and is far from an "outrageous amount of processing power" on modern computers.
Is their a more efficient way to store this data keeping all of the data in order?
Yes. If your game is deterministic, all you have to store is the player's input and one game state 5 seconds ago. When rolling back, reset the game state and replay user inputs to recompute each frame data.
See this question for interesing discussion on how to design your own replay system on gamedev stackexchange.

Answer 2

I don't think an array of 300 relatively small elements will slow you down at all, have you tried profiling it yet?
That said you could store it in a vector and keep an iterator to the "current" and update that.

Answer 3

If you think storing 300 is a lot, store less, for example you can store 1/5 frames :
....|....|....|....|..*
* is your position, `/` the frames you will store and `....` other frames
and you don't have to copy all the saved data each time ... just delete the first and add one at the end, you can maybe use a std::list, you won't have to copy any data
in Every 5 frames you will call myList.pop_front(); the oldest frame and myList.push_back(); the newest

Answer 4

I don't think the storage requirement is THAT harsh - even with 300 frames this small object will take up much less memory than your average texture.
I suggest you avoid using a raw array and look at using a std::vector which is almost as efficient and will automatically resize as you need more buffer space (that way if you suddenly need 8 second or the fps goes up to 100 you aren't going to suddenly run out of buffer space). This also resolves your difficulty with unfilled 'slots' as the vector has a known size that you can efficiently access.
I also might suggest that you don't need to store every frame - games like Prince of Persia that do this trick if you watch them carefully are much less smooth when time runs backwards suggesting that they perhaps only store every few frames or something like twice a second as opposed to every frame.

Answer 5

Unless you're running on an MCU, data sizes (given the structures you've provided) will be negligible compared to the rest of your game (~10K, if I calculated it correctly, is nothing for modern PCs).
CPU-wise, moving data in a manner you've specified and on every frame, MIGHT be sub-optimal (it will move around 10K 60 times per second, or 600K per second, which MIGHT - though probably won't - be noticeable). IF it becomes a concern, I'd go for a circular buffer (for example, as in boost::circular_buffer), or for a std::deque or std::list (with deque probably being my first choice); all of them have O(1) insertion/deletion time, and insertion/deletion is what you need most of the time. Theoretically, there is also an option to use memmove() to speed things up without changing things much, but it is quite error-prone, and still has O(N) complexity, so I'd rather not do it.

Answer 6

Indeed, you could do less operations per frame to store the state.
You could use a std::vector. Then, at each frame, push_back() the new state and if(vector.size() > 300), then do a pop_front().
If you think it's not enough, just save less frequently (each half a second). When you roll back your info, you could do an interpolation between values.
Edit:
you're damn right Othman, vector doesn't have pop_front, so you can use vector.erase(vector.begin()) instead :) So you don't have to use linked lists.