Speaking as someone who's used both ZSNES and SNES9X for TAS production, I think ZSNES is worth a look for simpler TASes.
Pros of ZSNES:
Rewind button means you don't have to worry about maintaining multiple savestates.
Cons:
Random desyncs are more common due to core randomness (also seems to happen if you loaded a state after rewinding during the recording process)
Lack of Memory Watch and Input Display makes it unsuitable for high-complexity TASes (Super Mario World, for example.)
Just wanted to put this out there.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ZSNES does sort of have memory viewing the cheat editor. If you want input display for a video after it's made, we have a tool to display input from a ZMV using the on screen commentary ZSNES has built in.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
ZSNES does sort of have memory viewing the cheat editor.
I was aware of that, but there's no way to keep an eye on it short of playing entirely in frame advance and checking the cheat editor after every frame. I don't think that's something a TAS-newbie is going to be doing.
If you want input display for a video after it's made, we have a tool to display input from a ZMV using the on screen commentary ZSNES has built in.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I only have a Linux binary at the moment.
I can provide a Windows one a bit later, once I find where I put the source code to it.
Edit:
Knock yourself out: http://tasvideos.org/~nach/ezp.zip
Although note we haven't updated this in a while, so let me know if it gives you any issues with newer movies.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I... don't think it's really a good idea to advise potential new players to use the less sync-stable emulator just because it has rewind.
What would probably be better is to write a lua script to make rewind in snes9x, and post it, with instructions.
How fleeting are all human passions compared with the massive continuity of ducks.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Warp wrote:
Why cannot rewinding be added as a core feature to all emulators? It sounds like a very useful feature to me.
I agree with this statement completely.
It is part of the reason I've lost my motivation to continue the Mr. Chin run (Along with well, my sheer laziness >.>").
And? Savestates are cheap. Maybe it'd be a problem for N64 emulation, but the total RAM capacity of the SNES is only about 256kB; if you had to replicate all of that uncompressed for each savestate, you could store 600 frames' worth in 150MB of RAM.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It's a nontrivial chunk of change, yes, but it's not completely absurd. Basically what I'm saying is that a trivial brute-force implementation would still be quite usable.
Given the linear way in which rewinds are used (i.e. always loading the state at time T+1 before loading the state at time T), you could chop a large chunk off of that cost by just storing the difference in memory from one state to the next. Most of the memory shouldn't change in any given frame, after all. But that would make the difficulty in implementation significantly higher.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It's a nontrivial chunk of change, yes, but it's not completely absurd. Basically what I'm saying is that a trivial brute-force implementation would still be quite usable.
150mb certainly isn't much on modern machines. However, a reasonably smart implementation would only keep the last, say, 100-200 states in RAM and dump older ones to disk since rewinding that far would happen much less often than rewinding a few frames.
However, to store a complete history of states since power on for a one hour run would still take up over 50gb of storage which is clearly too much and suggests some optimisations are necessary...
Derakon wrote:
Given the linear way in which rewinds are used (i.e. always loading the state at time T+1 before loading the state at time T), you could chop a large chunk off of that cost by just storing the difference in memory from one state to the next. Most of the memory shouldn't change in any given frame, after all. But that would make the difficulty in implementation significantly higher.
...Like this. We can't store state deltas going backwards, but we can record them going forward and make, for example, every 50th frame a "key" state and write it completely. Then, to roll back to frame k, we load frame j = (k - (k mod 50)) and apply the saved differences from frame j+1 up to k. The last hundred or so states could still be cached in memory if this process was slow (it would probably only be noticeably slow when using a brute force script which rewinds).
I guess the question is whether it's possible to do a fast diff of each state against the last, especially on larger states like on the N64. Maybe some hooks could be added to the emulation code that add to a delta record for the current frame during memory/register writes?
Joined: 2/12/2008
Posts: 67
Location: San Francisco Bay Area, CA
Desty wrote:
I guess the question is whether it's possible to do a fast diff of each state against the last, especially on larger states like on the N64. Maybe some hooks could be added to the emulation code that add to a delta record for the current frame during memory/register writes?
It'd be interesting to see an analysis of how much (as a ratio) of the state of the machine that a typical game alters every frame. I'm curious: I have no idea what the average number would be.
There's three levels of change I anticipate; no-input (very minimal delta), movement (small delta), new area load (huge delta). Compression will utterly crush the first two into less than 1kb files.
I think this subject has been discussed in the past. An alternative option to save memory when using the rewinding feature is that the emulator doesn't create a savestate at each frame, but only each n frames (eg. each 10 or 20 frames or such). When the user wants to rewind by one frame, what the emulator does is that it loads the savestate prior to that wanted frame and then silently runs the recorded movie at full speed until the desired frame is reached. This happens under the hood so the user just sees the movie going one frame backwards.
Of course implementing this is slightly more complicated than a savestate-per-each-frame solution, but the memory usage can easily drop to 1/20 or even less. (The frequency of such autosaves could even be a configurable parameter.)
Your suggestion would also involve recording the player's input as a matter of course (or mean that rewinding isn't available when input isn't being recorded). I don't think that's necessarily a bad idea; I'm just pointing out a hidden assumption.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
Using an emulator for a TAS because of a beneficial and known bug wouldn't fly here. We try to use emulation that best replicates the actual console; using a bug like that is really no different than intentionally coding a faulty emulator to allow for all sorts of cheats.
The StarFox movie still irks me for this. Everything is too fast, some of it obscenely so. And I could have sworn that game was emulated at a correct speed at some point. Meh.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
It's actually fairly simple. You just save a memory diff each frame and keep them for the last ~1000 frames. Then, to rewind, apply them frame-by-frame while holding the rewind key.
