I can only conclude that it didn't desync, since you ended up in the correct final position. I don't know at this point how complete the sequence of events you describe is, but trying to reproduce it by following those steps again is probably the best way to find out. I can't get it to happen (besides the sound thing), are you able to get it to happen again? And can I see the movie file (if you still have it)?
ALAKTORN wrote:
while that is fixed, the screen now seems to be dying for a frame
Which frame is that? As soon as you hit load, or after frame advancing once from there? It goes back to normal afterward? Does it happen at the start of the first level or only in certain places? Does it happen even if you save and then load on the same frame? Are you using the latest version of the game now?
(You can always disable "Store Video Memory in Savestates" in the "Runtime > Performance" menu if you want it to act the way it did before.)
ALAKTORN wrote:
also another problem is that I can't unpause with spacebar for some reason, it pauses but doesn't unpause
(You figured this out already but) That's because spacebar is bound to the frame advance hotkey 2 by default, just disable it in the hotkey configuration if you don't want to use it as your frame advance key.
ALAKTORN wrote:
and I'm cucrrently writing this blindfolded by the game's window because it will givean error sound if I try to move it...
This game in particular has a bunch of weird issues with the window that don't show up in any other games that I've seen, but this issue doesn't happen for me. Is this only when the game is paused, or even when it's unpaused? Does it make a difference if you check and then uncheck the "Topmost" checkbox (and unpause the game)? What OS are you using again? (XP SP3?)
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
nitsuja wrote:
Lex wrote:
I just had a weird state-load problem.
I can only conclude that it didn't desync, since you ended up in the correct final position. I don't know at this point how complete the sequence of events you describe is, but trying to reproduce it by following those steps again is probably the best way to find out. I can't get it to happen (besides the sound thing), are you able to get it to happen again? And can I see the movie file (if you still have it)?
I watched it again. It seems I made a mistake. It wasn't the same input both times. Sorry about the false report!
I did find another bug while trying to reproduce it before I knew it was false though. The video doesn't update if you load a state after it's already reset to the opening screen after death. I was able to reproduce this part consistently. After that, if you try playing and you die (only known by death sound; didn't ram-search), the game sometimes crashes.
Geoffrey The Fly isn't a TASworthy game, but I'm hoping fixing Geoffrey The Fly bugs will improve Hourglass compatibility overall.
The video doesn't update if you load a state after it's already reset to the opening screen after death. ... After that ... the game sometimes crashes.
I think this is the same problem as not being able to load savestates across certain boundaries in other games, most commonly the title screen to gameplay transition but it depends on the game. If the layout of the game's memory changes too much in-between when the savestate is saved and when it's loaded, then part of the savestate will fail to load (with an error logged when it happens), which puts the game in a slightly inconsistent state and usually results in the game losing sound or video and/or inching closer towards crashing. It depends a lot on the game, some games (like Cave Story) almost never have problems like this once they get past the initial loading screen.
I'm not sure exactly what condition causes the savestate to fail to load, but it might be something I can work around with better savestate code.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
It's almost surely due to the heap, isn't it? Many Windows games "randomize" (not intentionally, of course) their addresses upon construction. New pointers are set upon heap construction/mapping. All one needs to know are the values of those pointers. CyberShadow would probably be able to help explain further. >.>
Well, since I've been dragged into this discussion already, I might as well ask: what did you mean when you said
the layout of the game's memory changes too much
? Hourglass could wrap memory management routines and simply never unmap any memory behind the scenes (and instead keep the address space so it could restore the memory at that address if needed). Or is the problem due to memory regions passed to sound/video APIs (surface/sound buffer memory)?
I don't think it's anything as granular as where memory gets allocated. Nothing would work if I relied on pointers staying in the same place in memory. And I allocate a fair amount of stuff on the heap myself so it would need to be handled well even if a game manages to never use it for anything.
It sounds pretty crazy/difficult to me to wrap all memory management, although maybe I'm not familiar with what you're referring to.
The actual error that happens is that VirtualAllocEx (with MEM_COMMIT|MEM_RESERVE) begins to fail on a region of pages it was previously working for. I don't know exactly what can cause that but I'm hoping it can be worked around by something as simple as splitting it up into multiple calls (either separate commits, or uncommit followed by commit).
I'm guessing the missing video issue is caused by a different problem, which is that system handles that were valid when the savestate was created won't be valid anymore if they get released and then the savestate is loaded. This one is a little easier to understand for me, and it might be possible to fix it straightforwardly (although perhaps only with a huge amount of effort).
while that is fixed, the screen now seems to be dying for a frame
Which frame is that? As soon as you hit load, or after frame advancing once from there? It goes back to normal afterward? Does it happen at the start of the first level or only in certain places? Does it happen even if you save and then load on the same frame? Are you using the latest version of the game now?
I don't remember well, but I think I had it after advancing 3 frames after a loadstate, and it happened pretty much always, that game seems to have a lot of graphics problems, when you loadstate it often keeps a superimposed image of a part of the screen it had before the loadstate too (different to what it did before, this one actually lasts I think forever until you loadstate again). about the picture, it only lasts 1 frame. haven't tried saving and reloading the same frame. I've always been using the latest version, Personman uses (used?) an older one
nitsuja wrote:
ALAKTORN wrote:
and I'm cucrrently writing this blindfolded by the game's window because it will givean error sound if I try to move it...
This game in particular has a bunch of weird issues with the window that don't show up in any other games that I've seen, but this issue doesn't happen for me. Is this only when the game is paused, or even when it's unpaused? Does it make a difference if you check and then uncheck the "Topmost" checkbox (and unpause the game)? What OS are you using again? (XP SP3?)
I think it was happening because Firefox opened a pop-up in the background and it somehow broke everything. paused or unpaused made no difference. haven't tried that. yes, XP SP3 (it also has a "professional" in between)
also I encountered another problem while TASing it, the movie file freezes for a couple seconds wherever I used savestates: the movie if you want to check, it's on stage 3
the movie file freezes for a couple seconds wherever I used savestates
That's simply re-saving dead savestates in case you want to load them again later, which takes whatever usual brief moment it takes for you to make a savestate. Other people won't see that, and you won't see it either if you restart Hourglass or if you choose "Delete All Savestates" in the "Runtime > Performance" menu.
the movie file freezes for a couple seconds wherever I used savestates
That's simply re-saving dead savestates in case you want to load them again later, which takes whatever usual brief moment it takes for you to make a savestate. Other people won't see that, and you won't see it either if you restart Hourglass or if you choose "Delete All Savestates" in the "Runtime > Performance" menu.
I think you didn't understand, I meant during movie playback, not recording
but I've just encoded my run and it didn't give that problem, I don't know if it was because I was dumping avi or if it's fixed now...
the movie file freezes for a couple seconds wherever I used savestates
That's simply re-saving dead savestates in case you want to load them again later, which takes whatever usual brief moment it takes for you to make a savestate. Other people won't see that, and you won't see it either if you restart Hourglass or if you choose "Delete All Savestates" in the "Runtime > Performance" menu.
I think you didn't understand, I meant during movie playback, not recording
No, I meant during movie playback too... this is normal behavior (it's a feature that keeps your savestates fresh) and I listed the two existing ways to disable it.
ah ok, sorry
is it not possible to start recording from wherever you want? and I noticed after movie playback, even when it's finished you don't get control over the game, why is that?
From what I've read of this thread, it sounds like Hourglass savestates are incomplete -- they don't perfectly replicate the current state of the game but rely on the game to have e.g. properly loaded textures onto the graphics card. Deterministic games will be properly set up to load a savestate so long as you follow the proper set of steps to reach the point where the savestate was made. Thus you can't start recording from wherever you want because there's no history tracing back to a known deterministic point (program launch).
Feel free to correct me if I'm wrong; I admit I haven't read every post here. That's just the impression I've gotten. I'm amazed that Hourglass can even do as much as it does.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Derakon is close to, but not entirely correct. Hourglass savestates are incomplete due to a limitation caused by system resources called "handles". In windows, a Handle is a number that refers to a resource that has been opened by the operating system. If a program closes, all of its resource handles are closed by the operating system, and when the savestate is reloaded, the handle numbers in memory will refer to resources that are not guaranteed to be valid, let alone the expected resource.
For this reason, in order to load a savestate when the program has been closed and re-opened since the state was made, it is necessary to play the movie back from its beginning to the point where the savestate was made, and then re-save the state.
Graphics and textures are actually stored in the savestate, so long as "graphics->surface memory" is set to "system memory", as this forces the graphics to be kept in an accessible memory location. They may not be saved in other cases, because it is not always possible to read or write to the GPU's memory directly.
How fleeting are all human passions compared with the massive continuity of ducks.
There was a minor update. Super Marisa World should work now, and a sound crash bug (probably one of many) was fixed. Note that if you already downloaded something called r18, that was actually r19 (the name was briefly wrong).
ALAKTORN wrote:
Can you please re-test this in r19 and let me know if it still happens?
ALAKTORN wrote:
is it not possible to start recording from wherever you want?
If you mean you want to record a movie that starts from a savestate, no, that's pretty far away from being possible at the moment. If you mean you want to switch from playback to recording at any time, (you probably didn't mean that but) the normal way of doing it (switch to read+write mode and then save and load a savestate) should work.
ALAKTORN wrote:
and I noticed after movie playback, even when it's finished you don't get control over the game, why is that?
I decided not to give control after playback because (1) that would allow messing up the end of a movie that ends its input early, and (2) that would make it possible to lose work by forgetting that it's not recording your input.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
nitsuja wrote:
If you mean you want to switch from playback to recording at any time, (you probably didn't mean that but) the normal way of doing it (switch to read+write mode and then save and load a savestate) should work.
Woah! That's the normal way of doing it in emulators? In Worms Armageddon's TAS build (what I've used the most for TASing), there's a single "take control" bind, which works even while paused. It switches from "playback" (or "rerecording") mode to "recording" mode. It should really just be that easy.
I agree with ^. I see no reason why hourglass should be bound to the kind of silly existing TASing conventions.
Another related feature that would be really nice would be if playback automatically paused on the last frame of input, so that you can resume recording more easily.
And while I'm listing features, being able to set up an autosave that saves a state to a particular slot every time you record N frames after the last autosave would be wonderful, especially since you can't save state while holding down game buttons (at least not with the default shift+number binding), which makes saving states during long repetitive portions annoying. But then you screw up and really wish you had :P
EDIT: Also, the ability to record over a segment without changing its length or destroying the rest of the movie. I believe, unless I'm just a total scrub, that this is impossible without a hex editor at the moment? Even better of course would be the ability to shorten the movie, but that's significantly more complex and would be useful only when you find an improvement that doesn't cause a desync.
The 'record over a segment without changing the length' feature request may seem kind of silly, since obviously you're not improving the run's speed, and you can already use a hex editor. But I think if this feature were available, people would be much more willing to be fancy and entertaining in their runs, since they could concentrate on speed at first, and then quickly and easily test out alternate, entertaining movements by going back over already-optimized sections.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Thanks for the clarification, Upthorn. I really should have thought about system handles. I'd guess networked games would have similar issues with bound sockets...heh, is there any reason why you couldn't do a multiplayer Diablo 2 TAS now, running each instance of the game on the same computer?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
And while I'm listing features, being able to set up an autosave that saves a state to a particular slot every time you record N frames after the last autosave would be wonderful, especially since you can't save state while holding down game buttons (at least not with the default shift+number binding), which makes saving states during long repetitive portions annoying. But then you screw up and really wish you had :P
If it's just one autosave slot, I can't see this being useful, since you wouldn't be able to predict whether the last autosave it will have made is at a good time (it might have saved before you did something you want to keep, or after you made the mistake). I think a usable version of this basically amounts to a request for a "rewind" feature... which I guess there's no reason couldn't be an option, although savestates are too heavy and/or unstable in some games to want to use it for them.
Note that if you screw up without having made a savestate recently, you can of course recover by switching to read-only mode and loading a savestate from sometime before you screwed up, then switching back to recording once it reaches the part you want to keep. There's already never a case where you would have to throw anything out just because you forgot to make a savestate at a certain point.
Personman wrote:
Also, the ability to record over a segment without changing its length or destroying the rest of the movie.
Either "multitrack recording" or "input slice" features would give you this, I think. These would all be used quite rarely since it's so easy to desync the rest of the movie this way (even with the simplest version of it). But they're useful features to have available.
Lex wrote:
there's a single "take control" bind, which works even while paused. It switches from "playback" (or "rerecording") mode to "recording" mode. It should really just be that easy.
There is actually a "resume recording" command which can be bound to a hotkey, although currently it also switches to a new movie file. I guess I should add another version that continues within the same movie, but I would never advise anyone to actually use that instead of the regular "load a savestate" method. The thinking was:
- When switching to recording you'll want to make a savestate there anyway if you're planning to do anything that requires any precision, so a separate "take control" hotkey wouldn't actually save you much time, especially considering that it would become yet another hotkey to remember to press in this specific situation. And when going in the other direction, from recording to playback, there would be no equivalently-special hotkey to do it unless you want a whole set of "switch to playback from state #" hotkeys. (I can see it being useful for more "casual" situations than making an optimized TAS, though.)
- If you're watching somebody else's movie file, and you decide you want to start recording (either to play around in an area or to see if part of the movie can be improved), the normal problem here is that you don't want to overwrite the rest of their movie in the process, and it's a pain to switch out of the program and make a copy of the movie then switch to the new movie just so you can avoid overwriting the original. This is the problem that the "resume recording to different file" command was intended to solve.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Oh, well WA's rerecording uses a new replay (input file) for each redub (rerecord). That's definitely not a problem, assuming each new file has the number of redubs in its filename.
I'm personally used to working like this, for example:
Although, a format which integrates what all those files do together into one file would be ideal, as long as you could cut the fat when you wanted to publish it.
If you mean you want to switch from playback to recording at any time, (you probably didn't mean that but) the normal way of doing it (switch to read+write mode and then save and load a savestate) should work.
Woah! That's the normal way of doing it in emulators? In Worms Armageddon's TAS build (what I've used the most for TASing), there's a single "take control" bind, which works even while paused. It switches from "playback" (or "rerecording") mode to "recording" mode. It should really just be that easy.
In normal emulators there's not a problem with this, because you want a savestate right where you start recording etc etc. However, in hourglass, because there are still issues where some games crash for me pretty frequently when savestates are loaded, I would really appreciate the ability to resume recording without mucking with savestates.
How fleeting are all human passions compared with the massive continuity of ducks.
However, in hourglass, because there are still issues where some games crash for me pretty frequently when savestates are loaded, I would really appreciate the ability to resume recording without mucking with savestates.
I added this feature just now, although I don't think savestate instability on its own is a valid reason to prefer it. I think the case of loading the same frame you're already on is completely stable even for games that would "normally" crash, since all it's doing is reading some bytes and writing back the exact same values at the exact same locations, which even if it somehow fails will still leave the correct values in memory because they were already there. The usual uncertainties are removed in that situation.
However, in hourglass, because there are still issues where some games crash for me pretty frequently when savestates are loaded, I would really appreciate the ability to resume recording without mucking with savestates.
I added this feature just now, although I don't think savestate instability on its own is a valid reason to prefer it. I think the case of loading the same frame you're already on is completely stable even for games that would "normally" crash
This is definitely not true for eversion under Windows 7 x64. I'm not surprised if this is being caused by an additional layer of instability that is added by x64, but it definitely happens and can be very frustrating to deal with.
How fleeting are all human passions compared with the massive continuity of ducks.
This is definitely not true for eversion under Windows 7 x64. I'm not surprised if this is being caused by an additional layer of instability that is added by x64, but it definitely happens and can be very frustrating to deal with.
Hmm, that could be something else... can you try this and see if it makes Eversion more stable?
- Runtime > Disable Pause Helper
- Runtime > Multithreading Mode > Disable
When TASing a Windows game, what screen resolution should we use? Because in my side, my maximum resolution is 1920x1080, while there are games that can go further than that.
And also, if we encode a Windows game, is that possible to choose another resolution than the one used for TASing, or will it cause desyncing? For example, if someone TAS a PC game at 640x480, and I want to make an HD encode out of this, I'd have to set the resolution to something like 1280x720 or 1920x1080 (if the game supports it, of course). Would it be possible?
- When switching to recording you'll want to make a savestate there anyway if you're planning to do anything that requires any precision, so a separate "take control" hotkey wouldn't actually save you much time, especially considering that it would become yet another hotkey to remember to press in this specific situation. And when going in the other direction, from recording to playback, there would be no equivalently-special hotkey to do it unless you want a whole set of "switch to playback from state #" hotkeys. (I can see it being useful for more "casual" situations than making an optimized TAS, though.)
I believe that every skilled TASer should be capable of recording a good chunk of input using only frame-advance and no savestate at all. I've been using the Resume/Exit Recording feature in VBA-RR a lot as it does have saved time for me. That is to say, such a feature can be useful.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Although, a format which integrates what all those files do together into one file would be ideal, as long as you could cut the fat when you wanted to publish it.
