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.
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
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.
How fleeting are all human passions compared with the massive continuity of ducks.
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.
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.
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
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
For testing's sake, I tested TASing a random Windows game.
It is a free puzzle/shmup game called Nova 3000.
Here is a test run.
It completes the first level in about 2 minutes, then exits the game.
315 rerecords, never experienced any desynchs.
I used hourglass-r20, 60 FPS, multithreading disabled.
The only problem was that the game used some pop-up windows, which were not displayed correctly. Otherwise, it seems fully TASable.
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.
1.73 had a completely new world 8, minor level/enemy changes, and replaced Cocoron's music with a weirder variant of it, but is mostly the same as 1.6 otherwise. I haven't played the older versions and they're not available from the homepage, so I can't tell for those ...
"any%, good ending" being possible at all is a bug, also related to the odd deaths. If I'm at an evert point (from falling) when it goes back to "Ready!", the evert point stays active and I can evert up or down (but not both) anytime until I hit another evert point. I used the bug once to evert up to 8 (and reach world 8) without getting all gems, and again in world 8 as a shortcut.
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
Initial tests of the new version indicates that F2 works fine; I might have continued my run but right now I have a bunch of stuff to do.
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.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
I managed to run Jazz Jackrabbit 2 (registered 1.2 version) on Hourglass with these options:
Multithreading Mode -> Disable (prevent thread creation)
Message Sync Mode -> Unchecked (native messaging)
I tested also a The Secret Files 1.42 version released by LK Avalon and it freezes after running it.
I'll try to TAS JJ2 if I manage to overcome that annoying crashing after making a savestate.
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).
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.
I'm having some trouble running Bunny Must Die.. the strange thing is that it worked with the r11 version - now in r39 the bmd.exe *32 process launches, but it doesn't create a window (or even change the graphic style back to windows classic).
The issues I had with r11 were that on loading savestates, the game would stop drawing forever (game logic and sound still worked fine), unless I used Surface Memory -> System Memory, but this caused the game to run much slower and with bugged sprites everywhere.
In r39 I've tried running fullscreen, windowed, with multithreading disabled, without DirectSound creation.. with neither combination bmd.exe creates a window. Also, when I hit "stop running", the bmd.exe process lingers in the memory (although it stops running at 25% CPU time (expected? CPU with 4 "cores"..) and making my computer seemingly explode from heat).
Any ideas on what could be happening? Also why did it work in r11 and not in r39?
Running bmd.exe with the update patch and english patch; Windows 7 64bit, ATI Mobility Radeon HD 4650.
(On a side note... why all the interest in Perfect Cherry Blossom? If it's about scoring.. in this game it's pretty much all about "milking" spellcards - meaning waiting until each one of them almost times out, while you accumulate points from grazing bullets...)
I'll explain step by step what I did because I don't even understand how this is possible.
I tried downloading some older releases between r39 and r11 to see if any of them worked (downloaded r20 then r15). Neither did, so I tried to download again r11 to make sure it wasn't some config thing.
I renamed the old "hourglass-r11" folder to "hourglass-r11-2" and extracted r11 again.
..it didn't work, so I tried my old working version of r11 (in the "-2" folder), and it didn't work.
I was completely wtfed by this since it was working before I renamed the folder... I tried naming it back to "hourglass-r11", and that does make it work again.
Now I have no idea why one r11 works and the other doesn't, and why the old r11 MUST be in a folder named "hourglass-r11" to work.
Supposedly the only different thing about the two r11 folders is the bmd.wtf file present in the old one, but copying it around to the other folders doesn't help...
EDIT> just to clarify things... hourglass lauches with no problem every single time, when I say "it doesn't work" I mean that when I Run and Record New Movie, bmd.exe doesn't create a window.
Also, this is strange enough that I'll try to restart the whole system. No idea how this would help, but then again I've no idea how is it possible that in two identical installations, one works and the other doesn't.
Would be double post>
After restarting, r39 works. There was some unnamed process running in the background, that needed to be force-killed when restarting the system though - maybe some weird cached form of the old r11 hourglass.exe persisted in memory?
..I thought Windows had given up on using magic ever since the bad experience with Windows ME, but apparently they brought it back in Seven.
Finally... the "bmd stops drawing forever (but keeps running normally other than that) after loading a savestate" still exists.
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.
I forgot to write that I'm using that option only for fixing a starting logo - without Unchecked option it's black. The game plays fine with only disabled multithread.
Unfortunately, Hourglass doesn't playback the recorded movie - it behaves like movie file doesn't exist.
On a side note... why all the interest in Perfect Cherry Blossom? If it's about scoring.. in this game it's pretty much all about "milking" spellcards - meaning waiting until each one of them almost times out, while you accumulate points from grazing bullets...
That is mostly correct. However, due to tool-assisted precision, quite more risks can be taken, culminating in creation of unprecedented strategies. PCB is the one Touhou game that can benefit from this the most. This is an example, but keep in mind that it's not very well-researched. Much more is possible.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
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.)
<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
I guess ATI Radeon strikes again =/
Store Video Memory in Savestates makes no difference, but chaging the graphics card to Core i5's Intel HD makes it work perfectly (sorry for not testing this before).
Using the ATI card, loading a savestate in the same paused frame either works or hourglass decides that the game has crashed (rarely - DirectSound creation disabled doesn't fix this).
Creating a savestate, stepping one frame, then loading the savestate always makes the game stop drawing, and most of the times makes hourglass say the game crashed.
I'm saying that "hourglass says the game crashed" and not "the game crashes" because well, the game doesn't seem crashed.. even if hourglass closes its window at the end of the next frame, I can still listen to the game working for 1 frame, and in the case of loading a savestate in the same frame that it's created, I can see the game running for 1 frame.
In any case, we should ask Upthorn if his card is an ATI Radeon... these cards are infamous for having compatibility issues, and lacking some useful instructions.
When I run the game in windowed mode, there's a small margin in the bottom of the window that stays black normally. When I save, wait a frame, and load a savestate, with any of the two grafic processors, the game's frame "stretches out" to occupy the whole window, including this small margin. With the Intel HD processor, the game then keeps drawing without stretching (doesn't draw in the margin until I load a savestate) ; with the ATI card though, it stays frozen with the stretched image forever.
...maybe it's a layering issue? A friend of mine working on a game engine ran into a problem like this when working with ATI cards and Direct3D. For some reason, ATI cards would not render an object B created at z=1, when there was an object A created earlier at z=0. It assumed that B was completely covered by A.
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).
Using the ATI card, loading a savestate in the same paused frame either works or hourglass decides that the game has crashed (rarely - DirectSound creation disabled doesn't fix this).
Creating a savestate, stepping one frame, then loading the savestate always makes the game stop drawing, and most of the times makes hourglass say the game crashed.
I'm also experiencing this issue on my laptop (which uses a radeon). I didn't really test on this game before hourglass was released, I just made sure that it was running at all, whereas previously it was always freezing up before the window even got drawn.
How fleeting are all human passions compared with the massive continuity of ducks.
For some reason, RosenkreuzStilette gets crashed as soon as it is called by Hourglass, im using the version 1.06b or something like that, do i have to wait for another version of Hourglass? Or i am doing something wrong?
Can you give any examples of games that require a joystick but would otherwise be TASable?
Return of Egypt?
<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
