Rewinder - lift 16k state limit

[nattthebear]

Regardless of the target frame length and buffer size, the rewinder will not store more than 16383 states. A 4GB buffer with 50KB states, both reasonable numbers, would need an 80000 state capacity, so it seems likely we'll go over this. It's not difficult to up this number, I just need some time to think about properly architecting it.

[adelikat]

In the meantime that is about 4.5 minutes of rewind time (at an interval of 1), I think that's plenty for reasonable use cases

[Morilli]

It's not difficult to up this number, I just need some time to think about properly architecting it.

Don't quite know what to make of this statement. From a quick glance at the code it seems like this number is just used as a bitmask for a ringbuffer. Any difficulty or issue in increasing the number of used bits?

[nattthebear]

If you increase the hardcoded value, then everyone pays more memory, even though most won't use anywhere near that many states as adelikat points out.

[Morilli]

I see the point, but from what I read the current size is (8 + 4 + 4) * 0x3FFF = 256KB, no? Increasing that by 16x to 4MB shouldn't be an issue really and at least resolve all immediate issues from what I can see.

[nattthebear]

Why would anyone ever need a rewinder that big? Since we don't offer random access, you'd have to sit there and rewind for an hour just to get to the earlier states. If you're doing a major project, you need to use actual savestates and we shouldn't try to cram the square peg into the tomato.