wow awesome so far. :) i just knew someone would be interested considering how close it is to megaman games. :) I'm defintely going to follow this.
There's actually more now (and this too). Although I'm having trouble running this game myself so I wonder what options and system setup they're using. But at least we know it's possible.
Things other people mentioned in this thread that I know are definitely TASable already:
- Cave Story
- Iji
- IWBTG
- Eversion
- Bunny Must Die
- Ika-chan
- La-Mulana
- Streets of Rage Remake
- Syobon Action
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think the CRT is often statically linked, in which case I wouldn't know how to hook rand() since it's not exported by the game and I don't know its address. It might be easier to find _holdrand in the _tiddata in the game's TEB, or expose the TLS slots as if they're at fixed addresses.
Another possibility is: save a state, call rand() in a thread of interest, compare the savestate with current memory to determine which address the seed is stored at (since it's the only thing that should have changed), then overwrite the seed with the old value and cache its address.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Note that someone has made a test TAS of an any% route which you can see here: (parts 123). I thought the third part was especially good.
Any%, 100%, and low% all sound interesting to me, in roughly that order. For low% I think 4 keys + 2 time powerups (which means no dash boots and no wallkick, if I read correctly) feels like the "lowest"% run you could do, which I would go with simply to make it as different as possible from the any%.
Can you give any examples of games that require a joystick but would otherwise be TASable? Adding mouse support seems more important than joypad support at the moment. There is already "JoyToKey"-ish support for games that you would prefer to play using a gamepad, but no "KeyToJoy"-ish support yet.
brocoli wrote:
and most of the times makes hourglass say the game crashed.
Assuming you didn't disable "load all symbols" or "debug logging", there should be a stack trace of the crash near the end of hourglasslog.txt when that happens... could I see it? Also, try it with threads disabled and/or directsound disabled (since fewer threads running means fewer possible places for it to crash). I guess there are other display settings you could play around with too (such as disabling "write combining" or lowering the hardware acceleration level). I realize you got it working with a different video card, I'm just looking for more information about how it acts on the other one. By the way, I happen to be using an ATI Radeon at the moment without such problems (but it's a much older model than yours).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
brocoli wrote:
but then again I've no idea how is it possible that in two identical installations, one works and the other doesn't.
Maybe Windows had decided to apply some compatibility mode shims to one and not the other, based on the path name plus something else, and it got into some messed-up state that got cleared upon restarting. There does seem to be a lot of magic that goes into this compatibility stuff, for example, if an application crashes, Windows patches it to change how it runs the next time, and if it stops crashing for "long enough", Windows changes it back to normal. I'm pretty sure XP didn't do that stuff, but Vista and Windows 7 do. It's probably ultimately the fault of something Hourglass is assuming, though... at some point I should get Windows 7 and iron out how Hourglass runs on it.
brocoli wrote:
Finally... the "bmd stops drawing forever (but keeps running normally other than that) after loading a savestate" still exists.
It happens every time, even if you load a savestate while the game is paused on the same frame after you saved it? Or is there some minimum elapsed number of frames before it happens? Does it make a difference if you enable/disable "Store Video Memory in Savestates" in the Runtime > Performance menu? Otherwise, leave that enabled, and for now you said you already had a workaround (changing the graphics surface type) which should be better than nothing even if it has some annoying side effects. (By the way, I think Upthorn has a similar system to yours, but he hasn't reported this particular problem happening in BMD. If it really doesn't happen for him, I wonder what the difference is.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Truly awesome TAS, thanks for seeing it through. My favorite parts were the Deku Palace and the room with the updraft in Stone Tower, but basically the whole thing was entertaining.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Couldn't this have waited a bit longer for submission until Hourglass fully supported this game? There's a reason it isn't listed as being compatible yet. (I'm working on it...)
As for the run... I don't know. It's not a game I find really exciting, but then again the run isn't that bad, it's under 5 minutes, and it got more interesting as it went along and buffs started appearing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
You mean when the game is running normally, or when it's running in Hourglass, or both? I don't get this problem either way in Mario XP on my XP SP3 system. Try running it in Hourglass with default settings, and then (if that doesn't change anything) try running it in Hourglass with multithreading set to Disabled (which effectively disables the audio in Mario XP).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
In the latest version, there is now an "App Locale" option in the Runtime menu for simulating what Microsoft's AppLocale does (to a limited extent), mainly so that (the original versions of) games such as SyobonAction or Perfect Cherry Blossom or Cave Story can run and display correctly in Hourglass without needing to set your whole system's language to Japanese. The real AppLocale definitely does the job more extensively, but it's sort-of deprecated and probably wouldn't get along with Hourglass anyway, so I thought this should be a built-in option.
Note that you still need the correct fonts installed for it to look right. Supposedly they come pre-installed on Vista and Windows 7, and if you haven't installed them yet on XP you should be able to do so by following steps 1 through 4 here.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I had no trouble making an encode of this, maybe you're having problems related to the codecs you're trying to use? (If not, it would be great if you could compile Hourglass so that you can tell me where it crashes.) I also didn't need to check "allow fullscreen", as this isn't a fullscreen game by default (and my display is set to 32-bit already). However, whatever this game uses to play its sound isn't supported at all yet.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
(Can you say what version of Hourglass you used and what your OS is?)
You're supposed to always disable multithreading before starting the game when TASing it, if the game has stability problems. If you don't do that, then that's the most likely reason for any given crash you get. (Hopefully this is a temporary situation until some more bugs get fixed.) If that option doesn't work at all... well, it's supposed to work, and it works for me on this game on XP at least. (There are some fallback options you could try such as disabling DirectSound in the sound menu or using some of the other options in the multithreading menu.)
But, this game isn't really supported yet, and even if the above suggestion helps it won't fix all of the problems you're getting. This game has its own unique set of problems, and while some of those might be easy to fix, I haven't looked into fixing them yet (and I'm surprised it runs at all, considering that). Although, if you're able to work well enough to produce a TAS in the meantime and you're sure you want to focus on this particular game... I guess the only thing that's actually required would be support for capturing MIDI to AVI, which is something needed for Eternal Daughter as well.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Hero Core is actually pretty fun to play, and it seems to be good for TASing as well. I made a test TAS earlier, here's the movie file (and here's an encode that I already linked to elsewhere). This is only an any% run on Normal difficulty, so it's possibly the least-interesting type of playthrough. Each difficulty mode in this game takes place on a completely different map (and at least one of them has unique story elements and boss battles), and they could have 100% runs done of them too.
The movie file was recorded with Hero Core 1.1 but it syncs in 1.2 also. This game's "fullscreen" mode doesn't work that well in Hourglass, so (if you don't use the 1.1 version I just linked to, which is pre-configured) I suggest setting the game to run in windowed mode first, otherwise you might not hear any sound. You have to change the fullscreen setting in the options/controls menu and then back out of the menu before quitting in order for the change to be saved.
Oh, and here's an encode of the (secret) hardest difficulty mode that I also posted earlier. I haven't gotten this one's movie file to sync in the latest Hourglass yet. One interesting note is that the game's author actually made a TAS of sorts of this same difficulty mode and put it on Youtube here. (Not having Hourglass, he used a version of the game that he modified to have savestates and slow motion and some amount of automatic player movement.) I'm pretty sure my version is much faster, and yet, still far from optimal because this mode is so incredibly hard even under TAS conditions.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Parseus wrote:
Message Sync Mode -> Unchecked (native messaging)
Any option that says "asynchronous" or "unchecked" is almost guaranteed to cause desyncs all over the place. If a game requires that option (and doesn't work with some other combinations of options as a substitute), it means that the game might work in the future if the messaging code is updated enough, but the game won't really work yet as far as movie playback goes.
Ferret Warlord wrote:
Also, I've been getting some wildly varied frame rates from this game. 45, 40, 47.6, 55. I'm not sure what do do about that.
That could be normal, although maybe not. It could even be a problem with the accuracy of the framerate display itself. If you try dumping an AVI of it, does it play back noticeably slower than the game should actually run? If so... it's probably related to the way this game uses dirty regions which makes it hard to guess when the game intends a new frame to be drawn. One other game I know of with a similar issue is Lyle in Cube Sector (although the first AVI uploaded of that looked as laggy as it did mainly because it was set to the wrong framerate). I have an idea of how to fix this, but it requires fundamentally changing how frames are detected and might not get implemented for a while. In the meantime, if the game runs at almost the correct speed then the current way might be "good enough" for this game for now (like how things often are with the timing accuracy of emulators).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Phallosvogel wrote:
I've found this test run on nico video. Its scary how many results you already get if you just search for 'hourglass'.
It looks like he finished this test run, and made a post about it here complete with encodes on Youtube and a link to the movie file, which synced for me with Hourglass r35 and untranslated Doukutsu 1.0.0.6.
I see lots of suboptimal movement here at the very least, but I guess that makes sense considering the low rerecord count (6673 rerecords for 54 minutes) and the likelihood that he wasn't watching the speed values in memory either.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
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.
Try with the latest version, it should be fixed now. Hopefully the fix didn't introduce any desyncs...
Aqfaq wrote:
For testing's sake, I tested TASing a random Windows game.
It is a free puzzle/shmup game called Nova 3000. ... The only problem was that the game used some pop-up windows, which were not displayed correctly. Otherwise, it seems fully TASable.
AVI capture didn't really work for this game. This should be fixed now too. (Well, it's still a little bit off due to some annoying frontbuffer-only effects, but that doesn't happen during the actual gameplay.) As a result of some related fixes, your test run doesn't quite sync anymore, though it might sync again if you delete the first frame or so. (Most other games are unaffected by this change.)
Acmlm wrote:
Eversion worked perfectly for me (version 1.73, Windows XP SP3), with default settings on Hourglass r4 (haven't tried the pause helper in newer revisions yet) ... I only had to disable multithreading to avoid random crashes when rerecording. It also runs at 50fps, not 60 as listed on that page.
I already have 2 complete test runs of it (both improvable) as well, and they sync fine with r20 here:
- "100%, good ending" in 9:27.04
- "any%, good ending" in 4:01.60
These synced fine for me (after I deleted my save file before watching each one). I found them pretty surprising and/or confusing, mainly because of what I assume are large differences from previous versions of the game, although I wasn't sure what some of the deaths were for either. Is it a bug or a secret that "any%, good ending" is even possible?
By the way, I tried "Scarlet Weather Rhapsody" and it's almost TASable, except it desyncs on playback due to having threaded loading screens. "Rosenkreuzstilette Freudenstachel" seems to have the same problem. I'm still trying to think of ways of making this type of loading screen deterministic.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
ALAKTORN wrote:
Phallosvogel wrote:
I've found this test run on nico video. Its scary how many results you already get if you just search for 'hourglass'.
is there no acceleration in this game? the guy does everything but optimize it
There is quite noticeable acceleration (although of course a TAS will try to make it look like there isn't, by staying at a high speed as much as possible), but yes, he doesn't seem to be optimizing the movement very well. One thing to note is that hitting a wall doesn't completely reduce your speed value to zero (I think this is one of the tricks this game does to make the controls feel more responsive), but it still reduces it to roughly half of your regular movement speed, so hitting a wall only slows you down if you would have exceeded that speed before clearing it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I'd vote for staying with Impossible difficulty. The game goes out of its way to remind you of it if you're in Medium difficulty (by putting a pink bow in your hair for the whole game and printing WUSS on half of the save boxes) and I think the perception that you're not playing on the hardest difficulty will decrease the entertainment value in this case. Plus Medium really is a little "easier" even for a TASer because the save abuse lets you skip parts that you would otherwise have to do. Also, saving the game should generally be avoided in any game where it's possible to do so, for now, because Hourglass doesn't support it very well yet (it could cause desyncs unless you manually delete the save file every time the movie starts).
Here's 11 frames faster to the polar star chest. I'm not sure what the conditions are for reaching 845 speed or whether it's possible to exceed that.
(EDIT: this is for the same version of the game Upthorn's movie was for: Doukutsu 1.0.0.6 with English translation 1.03)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I added a Compatiblity List page with a somewhat more complete list of supported games, which also includes recommended settings and game-specific issues (when known). "videos exist" means that I know somebody other than me has already uploaded a TAS WIP of that game online.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
Disabling pause helper doesn't seem to change anything. Disabling multithreading prevents eversion from proceeding past frame 2. It doesn't crash or anything, it just stalls. If I disable multithreading after getting to frame 3, that doesn't seem to change anything either.
That's different behavior than on my system, but then again I'm using a different OS and maybe a different version of Eversion also. If you can't disable multithreading, the next-best thing is usually to choose "Disable DirectSound Creation" in the sound menu, and there are other options to semi-disable multithreading in the menu (such as "allow unknown threads only") some of which might work too. I suggested disabling the pause helper because I traced a crash into that functionality in this game, so if you can get by without it I'd still leave it off for now in Eversion in case it helps a little.
EDIT: It could also be something completely different, but I think in Windows 7 they changed the implementation of DirectDraw to be multi-threaded (using timer queues internally) instead of being single-threaded, which would explain why I'm able to completely disable multithreading in Eversion and you're not. Maybe I should hook timer queues, or maybe I should add some way to "emulate" DirectDraw with software rendering similarly to how DirectSound is handled, so that it's not susceptible to this kind of OS difference.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Mister Epic wrote:
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?
All of the games that I've seen work in Hourglass so far pick their own resolution (such as 640x480) which is what it draws and what will go into the AVI, regardless of the window size or your actual screen resolution. Some games can be configured before running them in Hourglass (in-game or in a config file or through a separate config program) to use a different resolution, for example Cave Story can be set to either 320x240 or 640x480, and 640x480 should be preferred in that game because the text becomes more readable at that resolution even though the rest of the game's graphics simply get their pixels doubled. So far I haven't seen a game desync as a result of changing its display resolution, but there might be some games where it makes a difference in sync (especially mouse-using games, although these aren't supported yet anyway and there might be some hack that could be done to keep those in sync across different resolutions).
Another variable in the config options of some games is fullscreen vs. windowed mode. This I have seen affect sync, for example, Bunny Must Die starts up too slowly if it's set to windowed mode instead of fullscreen mode. Note that fullscreen mode is "faked" and runs inside a window too, even though the game thinks it's running in real fullscreen mode (unless you turn on the "allow fullscreen" option, which shouldn't be necessary except in games that aren't fully supported yet). I think this means that you could set the game to a resolution that your monitor doesn't actually support and it will still work as long as the game itself is programmed to support it, although that hasn't really been tested yet so it might require some fixes. In general, TASing in fake fullscreen mode should be preferred over TASing in the game's own windowed mode (for various reasons). For another example of where it makes a difference: Iji uses "gamma ramp" effects in fullscreen mode to implement smooth screen fades and lighting condition changes, which will show up in the AVI, but if you set the in-game options to windowed mode then these effects all disappear.
For games that use Direct3D or OpenGL, Hourglass could theoretically render the game at a higher resolution than it normally supports (e.g. by doubling the resolution the game asks for, pretending it isn't doubled, and inserting a 2x zoom into the D3D projection matrix). This feature doesn't currently exist, though, and would only work well in certain games.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
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
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think it's better to use the "slomo" version of IWBTG instead of the "frameskip" version. Otherwise I think you might get some unnecessary choppiness which would show up in AVIs too and could also mean lower TASing precision. Maybe the difference between them is quite small, though.
EDIT: Since both versions apparently sync with each other on playback of a full game TAS as long as the framerate is set to 50, I think that conclusively proves me wrong on the above point.
Also, there's a trick you didn't do in the room with the cloud platforms, where you can go over instead of under to get to the left side. I don't remember how much time it saves, though.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
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.
