The idea of creating a TAS sounds kind of interesting since I like to speedrun a few games. The problem is that when creating a TAS you have to make so many more choices. These choices include:
1. When to create a savestate
2. When to overwrite a savestate
3. When to load a savestate
4. If you choose to load a savestate which savestate to load
5. How many frames per second to play at and when to increase and decrease this amount
All of these choices have alot more depth to them than just choosing what button to press like when playing a speedrun. Whats worse is that since these choices aren't really gameplay related so they aren't that fun to make. It really feels like there should be some way to automate these things. Also in addition to this you have to worry about things like manipulating luck, desynchs, and hex editing when creating a TAS.
1. When to create a savestate
2. When to overwrite a savestate
3. When to load a savestate
4. If you choose to load a savestate which savestate to load
5. How many frames per second to play at and when to increase and decrease this amount.
1. Frequently
2. When you're reasonably sure you don't need to redo something from that point -- you can always replay your movie in read only mode to redo pretty much anything if need be
3. When you mess up
4. Load the closest one to where you messed up
5. Frame advance like evilchen said, or turbo when it's a long cut scene ;)
I do agree that tasing is much different from playing the game normally, but that's what I (and I imagine a lot of folks here) enjoy about it :)
1. When to create a savestate
2. When to overwrite a savestate
3. When to load a savestate
4. If you choose to load a savestate which savestate to load
Btw, those things would mostly go away if someone finally created a rewinding feature to the emulators (ie. like frame advance, but instead of going forward one frame, it goes back one frame).
1. When to create a savestate
2. When to overwrite a savestate
3. When to load a savestate
4. If you choose to load a savestate which savestate to load
Btw, those things would mostly go away if someone finally created a rewinding feature to the emulators (ie. like frame advance, but instead of going forward one frame, it goes back one frame).
As all variables on the machine state have to be preserved on each frame, it'll affect the speed while playing, and also have a buffer that limits the ammount of "undo" that you can do. You can use tricks like storing differentials ("on frame X value Y changed from A to B") instead of simply dumping all the same values every frame, but the space available still imposes a limit to the feature.
Suggestions include allowing the user to specify the max number of undo actions (like MS Word does).
In my opinion real speedruns offer more choices as you have to choose from which tricks you can preform consistently and which ones you can't.
While this is undoubtedly true in the long run (sorry for the pun), it can vary from game to game quite much. Like when you're pretty much forced either to go with one safe method or rely on luck completely in some highly nonlinear segment, in a TAS you're presented with a multitude of possible methods to go with, and even though in the end there will only be one-two optimal input sequences, finding them may prove to be hard, if not impossible, task. Games like Monopoly illustrate this pretty well.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 3/25/2006
Posts: 850
Location: stuck in Pandora's box HELLPP!!!
Warp wrote:
Btw, those things would mostly go away if someone finally created a rewinding feature to the emulators (ie. like frame advance, but instead of going forward one frame, it goes back one frame).
That should be quite easy with VBA, it's already got a rewind feuture. But it only goes down to 0.2 seconds (12 frames). Maybe it could be tweaked
1. When to create a savestate
2. When to overwrite a savestate
3. When to load a savestate
4. If you choose to load a savestate which savestate to load
Btw, those things would mostly go away if someone finally created a rewinding feature to the emulators (ie. like frame advance, but instead of going forward one frame, it goes back one frame).
I don't see how rewinding 1 frame would replace them.
I don't find that feature to be useful.
Btw, there is rewind feature in almost all emulators since long time now. FCEU, Zsnes, VBA and I think Snes9x too do have it.
As all variables on the machine state have to be preserved on each frame, it'll affect the speed while playing, and also have a buffer that limits the ammount of "undo" that you can do. You can use tricks like storing differentials ("on frame X value Y changed from A to B") instead of simply dumping all the same values every frame, but the space available still imposes a limit to the feature.
Speed and memory usage can be optimized more than that. For example, the emulator could store in memory a savestate for example for each 10th or 20th frame. When rewinding, it loads the previous savestate and silently "plays" it until the desired frame is reached. If, for example, it stored in memory a savestate each 20 frames and it used eg. 100 such savestates, the amount of possible rewinding would be 2000 frames, or 33 seconds. Tuning those values can allow even more.
Phil wrote:
I don't see how rewinding 1 frame would replace them. I don't find that feature to be useful.
One frame *at a time*. Naturally if you press it repeatedly, it will go back that many frames. This way if you made a mistake 5 frames earlier, you press it 5 times to get there.
(Naturally some maximum limit for going back is probably necessary in order to not to run out of memory, but we are still probably talking about thousands of frames which can be rewinded.)
The reason rewinding won't substitute loading a state is that loading is instantaneous and you can have states with multiple branches, while rewinding will only take you back to the beginning of the current branch, which I believe was what Phil was talking about. The "problems" described by gbagcn are not even problems at all if a player uses at least some form of savestate management (which they obviously should).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
I don't understand why rewinding couldn't be instantaneous (or at least so fast that you can't tell the difference). And it's not like rewinding would substitute normal savestates. It would just be an additional tool to make some things handier.
Well, rewinding, say, 100 frames back will take you noticeably more time than loading a state you made there, no? Assuming you won't go to options screen to readjust rewind intervals each time (that would kinda defeat the purpose of making stuff handier).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
going back a frame should be faster then going foreward one right? instead of calculating new values for some amount of memory, you simply recall them, and in both cases, you would re-render the frame?
There must be something Im missing.
going back a frame should be faster then going foreward one right? instead of calculating new values for some amount of memory, you simply recall them, and in both cases, you would re-render the frame?
There must be something Im missing.
What you're missing is that, when going forward, the CPU just applies some changes to the current state (so it only has to remember the current state, the changes are made "on the fly"). When going backward, the CPU has to store ALL previous states, as it's impossible to retrieve previous states from the current state when you are overwritting it every frame.
This wastes a lot of space, and you have to store it somewhere, temp files allow backtracking more frames, but also require access to the hard disc, which is thousand of times slower than RAM memory.
Those with a sizable amount of RAM could easily utilize some sort of auto save state functionality. You'd turn the feature on specifically for frame advance TASing. There's nothing wrong with the idea of having, say, 10-20 (user adjustable quantity) automatic save states created every n frames, where n is adjustable from 1 to 50, whatever the user wants. To 'rewind' while the game is paused, a hotkey is pressed, the current state is discarded, and replaced with either the immediately last savestate made, or perhaps a menu would allow selection of others (5 frames ago, 10 frames ago, etc). The user defined save states 1-9 would work as normal, and you'd be advised to save state before rewinding too far. What's wrong with that? Even storing the states entirely in computer RAM, your biggest system RAM to emulate is N64 with expansion pack, 8MB of RAM per savestate. Inefficient, yes, but we could still deal with it.
It is also worth noting that properly managing your savestates, and/or simply having more savestates, would make this unnecessary. The idea is that you have, at any given time, a slot saved within the last 30 frames, which is honestly not that hard even with 9 slots (depending heavily on experimentation level and the game itself, granted).
I think a "go to frame #"-option would be nice to have. It would load the movie (maybe generate an automatic savestate every x frames), and super fast forward (without displaying a picture or sound) to the desired frame. This would also help to check if the movie is still in sync (of course you don't use the savestates in that case).
I think a "go to frame #"-option would be nice to have. It would load the movie (maybe generate an automatic savestate every x frames), and super fast forward (without displaying a picture or sound) to the desired frame. This would also help to check if the movie is still in sync (of course you don't use the savestates in that case).
Snes9x v11 has that when you play a demo.
I think rewinding would be no problem if it used up 8mb per frame even, for me anyways. It would be totally optional of course, to those who have a big amount of ram like my 2gb but I think it should only rewind a maximum of 20 frames (more than that, get a save state :p), for example, you didn't set a save-state (or you don't want to go as far back as the other save-state) but you want to change a certain button-press just a few frames back, and don't want to replay the movie, set a state, restart the demo, jump-to, re-record, etc. It's a good idea to me though.
Well, rewinding, say, 100 frames back will take you noticeably more time than loading a state you made there, no? Assuming you won't go to options screen to readjust rewind intervals each time (that would kinda defeat the purpose of making stuff handier).
So what? If you want to go 100 frames back, then load that savestate of yours. If you want to go go 2 frames back, rewinding may be handier for that purpose. Why are you talking as if the rewinding function would *replace* savestates instead of existing besides them? If you don't like rewinding nobody forces you to use it.
Besides, nobody says there couldn't be a key combination (eg. ctrl + the rewind key) which goes back eg 10 frames to make it faster to go further back.
Joined: 12/27/2006
Posts: 532
Location: Göteborg, Sweden
At any keypoint of a movie, I make a "rewind" savestate, manually. This is usually save state 1 in the emulator. So whenever I need to redo something within the period of that state and the current frame, I press shift+8 (usually that's the shortcut for read-only) and I load the "rewind" state. When I think I've optimised a part of the movie, I put a new "rewind" state and keep playing. It really is that easy.
My published movies
[03:45:05] <Naohiro19> Soulrivers: ...
[03:45:19] <Soulrivers> ?
[03:46:35] <Naohiro19> <Soulrivers> No! <Naohiro19> So? <Soulrivers> Yes!
[03:46:48] <Naohiro19> joke
