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.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
50 is most accurate, 60 is wrong. I think Lyle v1.05 is actually handled more correctly timing-wise (because it uses a newer version of MMF) and it runs at precisely 50 FPS, but the music in that version currently doesn't work in Hourglass.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
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.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Here's my guess based on watching a couple of videos showing this bug: The bike can be thought of as a system of 3 points (one at the center of each wheel and one at the center of the larger bike-and-guy-on-bike compound sprite) that are connected by springs. The spring physics break down somewhat if any 2 of those points become exactly overlapping, resulting in the bug. Maybe what happens is that the game wants to push them away from each other but can't because they're at the same pixel position, so it builds up energy until something else nudges them slightly apart, at which point it applies a huge spring force to one of them which will be greater depending on how long they were overlapping.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
ALAKTORN wrote:
nitsuja wrote:
ALAKTORN wrote:
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.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
ALAKTORN wrote:
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.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
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).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Lex wrote:
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.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Note that Hourglass's RAM Search is currently only sufficient for very few games. If you can't find anything with it, you might try another program such as MHS. I would guess that addresses of integers found in MHS could be entered into the RAM Watch window once they are found.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
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)?
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?)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
By the way, I don't know if this will work for everyone, but here's a RAM Watch file that might help for a Cave Story TAS:
0
9
00000 0049E66C d s 0 X velocity
00001 0049E670 d s 0 Y velocity
00002 0049E654 d u 0 X pos
00003 0049E658 d s 0 Y pos
00004 0049E664 d s 0 X cam offset
00005 0049E660 w s 0 Y cam offset
00006 0049E6B0 w h 0 flags
00007 0049E6CC w s 0 health
00008 0049E1EC d u 0 framecounter
You should be able to save those into a .wch file and open it in the RAM Watch window in Hourglass.
Watching the X velocity value, it seems that the character has a continuously oscillating speed when on the ground that locks to something in the air (like in SNES Mario games, I think), which can probably be abused by always jumping at good speed values to go slightly faster than normal.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
There's a new version. It deals with the following reported issues:
ALAKTORN wrote:
when I loadstate the screen doesn't refresh, and I have to advance 1 frame to refresh it (making it very unprecise)
Masterjun wrote:
If I hold Shift and try to press the Frame Advance key ... it doesn't go to the next [frame].
(maybe fixed:) Lex wrote:
there's an issue with the "Stop Running" button not closing the process completely [on Vista].
Also, it should speed up fast-forward in certain games like MegaMari where it didn't do much before, and it should allow more games to be compatible with the "disable directsound" option which is useful for increasing TASing stability.
yuigenron wrote:
This problem also occured in my run, but most annoying one was frequent crashes...
In the newest version of Hourglass (currently r15), if you choose "Sound > Disable DirectSound Creation", this game should almost never crash anymore. Also, if you only load savestates from the current level/room, that should help a little too.
ALAKTORN wrote:
is it possible to show input / frame counter and all those nice things on screen? I can't find the option
Not yet, for now you'll just have to look at that stuff in the other window. It must be possible to add this feature but it's kind of annoying to implement it in a way that works in all these different games that render their screens in different ways.
Brandon wrote:
I got some kind of message when I wanted to load a state that was farther on in the game then I currently was at. That seemed odd to me. Should I assume states work very differently here? Instead of storing the actual state, does it just play back the input to that point or something?
Savestates are basically just RAM dumps, which are valid only within the current game session. If you close the game and reopen it and try to load an old savestate, that state is definitely not going to work anymore because it was from a previous instance of the game, and the new instance probably has different system handles and different memory layout, so the best Hourglass can do in that situation is play the input in fast-forward up to the frame the savestate was created on. Depending on the game that might only take a few seconds, but I think it's important to have a message telling you what it's about to do so that you don't think the game is randomly running out of control. Note that it automatically "revives" those invalid savestates by re-saving them if you watch the movie past where they were originally saved, which is why you usually won't see this message when loading a savestate that's in the past.
Brandon wrote:
did you happen to miss my latest post regarding a different game? The resulting screenshot is nothing short of bizarre, and I'm wondering what your thoughts on it are.
I didn't miss it, but I haven't looked into it yet. Most likely that game isn't supported right now for a bunch of different reasons that would have to be fixed anyway in order to get quite a few other games to boot up.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
Input is not yet working on Nothing, (probably a similar situation to Super Meat Boy, but different input library), not that it's a good TAS candidate yet, but I think it'd be fun to just play around with in Hourglass and experiment with knockback.
If it's just for testing, you can try setting "Runtime > Wait until sub-process creation" and "Runtime > Message Sync Mode > Unchecked (native messaging)".
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Hmm, I thought I fixed that slowdown bug already, maybe it reappeared. Also, try setting the framerate to 50 instead of 60 if you're not using 50 already.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Ferret Warlord wrote:
Fast forwarding makes everything look psychedelic
GDI games had the same issue, which is fixed, but I haven't applied that fix to DirectDraw games like this yet. As a temporary workaround, you can disable "Backbuffer Frameskip" in the "Tools > Fast-Forward Options" menu. But that option is usually an important part of what makes fast-forward so fast, so having it enabled after there's a fix for this case in the code would be better.
Ferret Warlord wrote:
and loading states in certain areas can garble the map a bit.
I wonder, if you disable hardware acceleration in the Graphics menu, does this still happen? And what's the earliest place I can reproduce this? (I think I know what you're talking about but I can't remember where I saw it before.)
Ferret Warlord wrote:
F2 allows you to reset the game at any time, permitting you to skip right over the opening introduction. Hourglass won't recognize that, so I think I'll have to record from a "dirty state" unless there's a workaround. I've already tried changing the game input for F2.
I think the input is being recognized, but whatever command this game uses to reset itself isn't implemented yet. It's probably something I disabled in the mistaken belief that no game would ever use it. Shouldn't be hard to fix, but there's no workaround I'd suggest until then.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I'll repeat what I said to ALAKTORN since I realized it might be helpful to other people getting similar issues:
ALAKTORN wrote:
I've tried TASing Ninja Senki, but I can't get through the main menu because it keeps crashing… I've tried disabling multithreading, but it doesn't help
Crashing after loading savestates? You have to be very careful to only load savestates when you're already on the same screen that the savestate is from, at least before the main gameplay starts and the game is still loading files. Also, disabling multithreading won't fix that particular between-screens issue but it definitely makes everything more stable, and keep in mind you have to disable it before you start running the game, of course. Try using just frame advance (at most) and no savestates until it gets into the level.
ALAKTORN wrote:
also, when I loadstate the screen doesn't refresh, and I have to advance 1 frame to refresh it (making it very unprecise)
This I'm fixing now and it'll be in the next version. Actually I already have a fix, I just have to find a way to make it not crash Perfect Cherry Blossom and then I'll update it.
Brandon wrote:
I'm on Vista. I realize now that Sakugarne Treasure Adventure v 3 doesn't even work for me regularly right now.
Ah. Yeah, if your system can't run it normally, then it's unlikely to work inside Hourglass either. (Although if enough parts of the OS are reimplemented in Hourglass it might be possible eventually.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Brandon wrote:
The only one I expect to have any success with is Sakugarne Treasure Adventure v3 as it doesn't use the mouse, but I tried many of these, and the best result I got was a window was created for some of them.
"Sakugarne Treasure Adventure v 3.exe" already works ok for me with the default options. The loading screen was all black and I had to wait a while for it to go away, and whenever the game tried to pop up a help window I couldn't see it and had to press escape to dismiss it so the game could unfreeze, but the actual game ran fine and synced on playback, and AVI video capture worked.
If you can't get it working after another try or two: What OS version are you on? If it's Vista, maybe the workaround Lex just mentioned works here too. Or you could try switching various settings to "allow" or "asynchronous" until it runs.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Lex wrote:
Hmm. I was only able to get Hourglass to run StickMan (and subsequently play the movie) after enabling "Allow loading any custom/installed DLLs". That info should be in the movie file. If safety/security is your goal, just use a warning like "Warning: This input file specifies 'Allow loading any custom/installed DLLs'. Play at your own risk."
You can't assume it acts that way on anyone else's system, so it wouldn't make sense to store it in the movie file (that option isn't needed for me and probably wasn't used by whoever recorded the movie either, and depending on what's installed it could cause all games to crash or desync).
Some of the options (such as this one) are only situationally useful and are likely to have negative side effects. To minimize the damage such options could cause if forgotten about, they are neither stored in the config file nor stored in movie files. If a game doesn't run with the default settings, that's a bug, which I'd rather fix at the source.
In this case, I'm guessing the problem is because the UserCallbackDispatcher hook currently has some OS-version-specific code for XP and Windows 7 but not Vista... it's the only place with that sort of code, and I'm still looking for a less brittle way of implementing it. Until I find it, maybe I should disable that hook if I detect that the OS is Vista (that is, if it's even possible to detect the current OS version without getting lied to by a compatibility layer).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Personman wrote:
It would be super cool if there was an easy way to correlate positions in the input file with frame numbers so I could go take them out!
Take the frame number times 8, add 1024, and that's the number of bytes the input is from the start of the file, which should be easy enough to change in a hex editor. The full movie format description is here.
But it would be a good idea to start over at some point and see how much you can improve it, especially if this is your first TAS.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Brandon wrote:
I can't seem to get this to work at all with my old Game Maker games. Any thoughts?
Which games, exactly? If I can get them, I can try adding support for them (by fixing bugs or adding missing implementations).
Sonikkustar wrote:
I couldnt get Lyle in Cube Sector working. Everytime I open it up, It freezes on frame 0. But it advances only by 1 frame when I click on the Hourglass window. Frame Advance doesnt work either.
What version of Hourglass are you using, what options have you tried changing, are you sure "Paused" isn't checked, what version of Lyle are you running, is it a fresh download, what OS are you on, and can I see your log file (hourglasslog.txt)?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Your movie synced fine on my end.
The style of killing enemies looks kind of sloppy to me, since there are unkilled enemies that could have been killed without wasting time, as well as missed shots. (It's ok to demonstrate how the shuriken stick into walls, but maybe it's better to do that in places where it's clearer that you're just fooling around, such as on screens that have no enemies.) Maybe it would also look more interesting/varied if there were more cases where your shuriken is 1 pixel away from missing the enemy or where you kill the enemy on the last frame you possibly can.
Also, since your movie currently syncs with both versions of the game in question, and probably only the newer one is being distributed at the moment, I suggest you download and switch to the new version when you continue recording. (But keep a backup of the old one somewhere, in case.)
EDIT: And the title screen looked pretty suboptimal (I think you can press the button to advance much earlier than that).
Personman wrote:
set the framerate to 60 fps
That's stored in the movie file, so there's no need to tell people what framerate to use.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Interesting, I didn't expect this game to be so close to working already. It probably doesn't record input or audio yet because it's using XInput and XAudio2 instead of DirectInput and DirectSound, but it's most likely not hard to add support for those newer technologies. Savestate support can't really be determined until after the audio is under control... it might be failing entirely because of the audio. There's still the possibility that the game is programmed using techniques that are too difficult to record deterministically, but with luck it might become fully TASable at some point.
