Gens+ REWiND! has been released.
Emulator found here.
Rewinding is another method for rerecording (along with state saving and loading), but this one... I don't know if it's for rerecording.
Implementing rerecording functions takes months.
It's too early to implement rerecording functions in an initially released emulator (i.e. v1.0).
With a big amount of memory, it should be possible with a lua script to save every frame in a file or in memory, and then if you want to rewind, you reload the previous frame SaveState. I know it would slow down the speed of the emulator, but the rewind feature might be useful for some people. I don't think it's hard to implement, and if could even be used only in certain part of a TAS where you want to try different combinaison :P
Just a thought
With a big amount of memory, it should be possible with a lua script to save every frame in a file or in memory, and then if you want to rewind, you reload the previous frame SaveState. I know it would slow down the speed of the emulator, but the rewind feature might be useful for some people. I don't think it's hard to implement, and if could even be used only in certain part of a TAS where you want to try different combinaison :P
Just a thought
Just what I was thinking.
Specifically, one can set a toggle key using a button on one of the unused joypads. Slowdown wouldn't be noticable in frame advance, but it becomes an issue if you have to fast-forward through many thousands of frames. Being able to activate and deactivate the extra processing is a necessity.
It is indeed easy to get such a thing to work on the most basic level. I've written as much myself a few times already. It's a half hour task.
I think we could do better, though. A movie is linear, but a TASer's mental process is likely to be tree-shaped. Try one path through a level, then with a different weapon equipped, then again hopping through it backward, and so on. Being able to not only store in memory, but visually represent each of the branches as one would use a version control system could be an interesting project for anyone inclined to take it up.
a TASer's mental process is likely to be tree-shaped. Try one path through a level, then with a different weapon equipped, then again hopping through it backward, and so on. Being able to not only store in memory, but visually represent each of the branches as one would use a version control system could be an interesting project for anyone inclined to take it up.
This is an idea I've been toying with for ages, but haven't been quite sure where to start in terms of getting work done on it -- the basic idea is that instead of having x slots for savestates, they're stored in a branching tree structure, and your hotkeys for dealing with them change from "previous slot/next slot/quicksave/quickload" to "previous branch/next branch/quicksave/skip back/skip forward"
Though obviously a visual branching timeline display would be almost prerequisite for dealing with states in this manner.
How fleeting are all human passions compared with the massive continuity of ducks.
I don't imagine this kind of functionality would appeal to the faint of heart anyway, so standard streams and SCM-style commands are probably the way to go. The visual component would entail naming the branches as the user creates them, via stdin. In addition to creating, checking out, and deleting branches, there would have to be a "list" command that shows the entire tree, with names, framecounts, and possibly other metadata to show, for instance, paths through the tree that sync properly, or other notes the TASer takes. Maybe a -v option for verbosity?
At least, that's how I'd want to use it. A graphical, mouse-based interface has never been my cup of tea.
...On the other hand, if Gens has mouse support (I seem to remember Nitsuja implementing such at some point) then you could conceivably do the whole thing in Lua, maybe having a directory representing a movie-tree, which would contain the savestates, as well as a metadata file describing the state hierarchy.
Implementing that as a plugin, rather than baking it into the emulator it might be an interesting direction for emulator development on the whole... but now I'm ranting.
Incidentally, sorry for not responding for so long; it was obscenely late when I wrote my last post, so I forgot having posted it until a couple hours ago.
