Feature Request: Instant Replay

[eyebrowsoffire]

I don't know if this is plausible but I've always thought this would be a really neat thing to implement:

It always has bothered me when sometimes when I use the rewind button in ZSNES, it comes out on a really awkward moment. I think it would be really cool if somehow ZSNES could be recording input as well as state saving like the rewind button does so that when you rewind, it plays back the input as well, and you can interrupt it at any moment. That takes away the possibility of rewinding and ending up in a spot where you were supposed to immediately provide input that you weren't ready for. Would this be a plausible thing to implement? Sometimes I do things in games that are neat and I'd like to see them played back, or better yet recorded, but I wasn't recording it at the time.

[ReRuss]

like how a tivo is constantly recording live TV (30 minutes constantly updating) and you can hit rewind to go back to see the last 10 minutes?

cept bein ZSNES I'm guessing it could record you like a ZST?

[Deathlike2]

Hmmm..

The rewind button is fairly good at what it is supposed to do. To get the kind of playback you need, there would need to be more frequent updates and buffering of the actions you made (probably others that I cannot think of at the top of my head).. This is unfortunately not really useful for normal gameplay (as neat as the idea sounds).. but rather useful for say the the movie recording/playback feature.

[Ichinisan]

It would be quite awesome if you could use a constant ZMV buffer to capture and game bugs that were impossible to reproduce intentionally.

TiVo-style rewind/playback is the best feature request I've heard in a long time.

If it's implemented, I propose that the playback interruption be triggered by simply pressing a button (any SNES-mapped button or input from SNES mouse/lightgun, etc) .

[eyebrowsoffire]

Hmmm..

The rewind button is fairly good at what it is supposed to do. To get the kind of playback you need, there would need to be more frequent updates and buffering of the actions you made (probably others that I cannot think of at the top of my head).. This is unfortunately not really useful for normal gameplay (as neat as the idea sounds).. but rather useful for say the the movie recording/playback feature.

I don't see how it could be any more taxing than the ZMV recording feature, combined with the usual save stating from the rewind feature. In fact, it might allow for less rewind updates because you could maybe have a save every 10 seconds or so and then when you rewind, you could wait for the moment you wanted. Basically what I'm suggesting is a beefed up version of the rewind button, with more precision and the extra feature of being able to see what you just did, in case it was amazing.

If it's implemented, I propose that the playback interruption be triggered by simply pressing a button (any SNES-mapped button or input from SNES mouse/lightgun, etc) .

Yeah that was what I was thinking for the playback interruption.

From a user's point of view, this seems plausible to me, but I'm not a developer. Can any of you developers out there tell me if this is a realistic request?

[Deathlike2]

I thought you wanted better rewinding (like per frame or something)...

One major thing may make this more difficult though.. the core randomness issue can screw this feature up. Until that is resolved, this suggested feature may produce various outcomes than originally expected.

[eyebrowsoffire]

I thought you wanted better rewinding (like per frame or something)...

One major thing may make this more difficult though.. the core randomness issue can screw this feature up. Until that is resolved, this suggested feature may produce various outcomes than originally expected.

Isn't that true about recorded ZMV files as well? I've had ZMV files do this to me, but not very often.

[grinvader]

"Not very often" jumps up to "annoyingly sometimes" the more you use ZMV records.
I.e.: not very high probability... but very irritating.

Also, the current ZMV format isn't able to do what you ask in a streamlined way. As you know, rewind saves a state every X frames.
If we made a feature saving a movie every X frames, lasting X-1 frames, the shorter the X, the more often you would end up with an unusably short interval recorded.
The longer the X, the lower the probability of such a situation - but it'll never reach 0 - and luck distribution says you'll get a new movie started since 0.012 seconds just as you want to rewind. Murphy's law, you know.

To prevent this... would require several current ZMVs recorded in overlay, and rotating... or a brand new FIFO-like ZMV format. Code-wise the former would be faster to pull, at a greater memory expense.
For a new format, a lot of time would be required.

[eyebrowsoffire]

"Not very often" jumps up to "annoyingly sometimes" the more you use ZMV records.
I.e.: not very high probability... but very irritating.

Also, the current ZMV format isn't able to do what you ask in a streamlined way. As you know, rewind saves a state every X frames.
If we made a feature saving a movie every X frames, lasting X-1 frames, the shorter the X, the more often you would end up with an unusably short interval recorded.
The longer the X, the lower the probability of such a situation - but it'll never reach 0 - and luck distribution says you'll get a new movie started since 0.012 seconds just as you want to rewind. Murphy's law, you know.

To prevent this... would require several current ZMVs recorded in overlay, and rotating... or a brand new FIFO-like ZMV format. Code-wise the former would be faster to pull, at a greater memory expense.
For a new format, a lot of time would be required.

That's a bummer. Well, I guess if you guys ever decide to overhaul the ZMV code, keep that in mind, I suppose.

[Nach]

"Not very often" jumps up to "annoyingly sometimes" the more you use ZMV records.
I.e.: not very high probability... but very irritating.

Also, the current ZMV format isn't able to do what you ask in a streamlined way. As you know, rewind saves a state every X frames.
If we made a feature saving a movie every X frames, lasting X-1 frames, the shorter the X, the more often you would end up with an unusably short interval recorded.
The longer the X, the lower the probability of such a situation - but it'll never reach 0 - and luck distribution says you'll get a new movie started since 0.012 seconds just as you want to rewind. Murphy's law, you know.

To prevent this... would require several current ZMVs recorded in overlay, and rotating... or a brand new FIFO-like ZMV format. Code-wise the former would be faster to pull, at a greater memory expense.
For a new format, a lot of time would be required.

That's a bummer. Well, I guess if you guys ever decide to overhaul the ZMV code, keep that in mind, I suppose.

We have overhauled the ZMV code.
Currently no other emulator hase movie support which even remotely matches what ZMV is capable of now.

To implement the requested feature here should be a simple matter of recording input, using the ZMV format for it would be overkill.

[eyebrowsoffire]

"Not very often" jumps up to "annoyingly sometimes" the more you use ZMV records.
I.e.: not very high probability... but very irritating.

Also, the current ZMV format isn't able to do what you ask in a streamlined way. As you know, rewind saves a state every X frames.
If we made a feature saving a movie every X frames, lasting X-1 frames, the shorter the X, the more often you would end up with an unusably short interval recorded.
The longer the X, the lower the probability of such a situation - but it'll never reach 0 - and luck distribution says you'll get a new movie started since 0.012 seconds just as you want to rewind. Murphy's law, you know.

To prevent this... would require several current ZMVs recorded in overlay, and rotating... or a brand new FIFO-like ZMV format. Code-wise the former would be faster to pull, at a greater memory expense.
For a new format, a lot of time would be required.

That's a bummer. Well, I guess if you guys ever decide to overhaul the ZMV code, keep that in mind, I suppose.

We have overhauled the ZMV code.
Currently no other emulator hase movie support which even remotely matches what ZMV is capable of now.

To implement the requested feature here should be a simple matter of recording input, using the ZMV format for it would be overkill.

Wait, so, basically what this adds up to is, using the ZMV format is overkill and would cause too many problems, but if you were to just record input this is doable?

[grinvader]

Well, it would also have randomness issues, but it would be feasible, I suppose. It's true that it wouldn't require any side feature, so using ZMV would reaaally be overkill.

Like using a space shuttle to go buy your bread next block.

[Poobah]

I also think that a feature like this would be extremely cool, even if it didn't syncronise perfectly.