Cave Story issues (not VS2010 build issues)

[GoogleCodeExporter]

Trying to "Run and Play Existing Movie" in Cave Story with the attached .wtf 
(which is a full test run I've watched in an earlier version of Hourglass) in 
Hourglass r63 causes Hourglass to do various things with various different 
configurations and sometimes seemingly random situations.  Here are some 
behaviors I've seen fiddling with enabling/disabling "Allow Fullscreen / 
Display Mode Changes" and "Yes" / "No" compatibility modes and trying many 
times.

-It runs 2 instances of the game, asking about compatibility mode twice in a 
row.  Both instances are windowed with blank grey surfaces instead of normal 
Cave Story video and are frozen on frame 0.
-The game crashes. (happens with "Allow Fullscreen / Display Mode Changes" 
disabled sometimes)
-The game starts in fullscreen mode but the movie visibly desyncs almost 
immediately.
-The game runs windowed and audio is heard, but the video is a blank grey 
surface.  I'm not sure whether it's desynced, but it sounds like it.  The video 
is always a blank grey surface with "Allow Fullscreen / Display Mode Changes" 
disabled.

I'm running Vista64.  These are some of the same issues I was seeing with my 
VS2010 builds of Hourglass.  All this didn't happen in earlier builds compiled 
with VS2008.

I can get logs if you want, but I figured if you can reproduce some of this, 
you'd be able to get the logs you need much more easily.

Original issue reported on code.google.com by lexlexlex@gmail.com on 24 Jul 2011 at 7:47

Attachments:

• jtDoukutsu.wtf

[GoogleCodeExporter]

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 7:48

[GoogleCodeExporter]

I can't reproduce this because I don't have Vista. I'll switch back to 
compiling with VS2008, then...

Original comment by nitsuja-@hotmail.com on 24 Jul 2011 at 5:21

[GoogleCodeExporter]

Oh and a full log of this would be helpful, though.

Original comment by nitsuja-@hotmail.com on 24 Jul 2011 at 5:21

[GoogleCodeExporter]

r64 binaries compiled with vs2008 have been uploaded.

Original comment by nitsuja-@hotmail.com on 24 Jul 2011 at 5:45

[GoogleCodeExporter]

The same things occur with r64.  So, it's not a VS2010 issue.  Sorry for the 
confusion.

This time, I did 2 things:

First, I ran r64 with Doukutsu.exe and jtDoukutsu.wtf ("Run and Play Existing 
Movie").  I had logging off.  2 instances of the game spawned, with each one 
asking me the compatibility mode question.  I pressed "Yes" to each one.  Their 
windows were in the same place, so I could only see one of them.  The video was 
a blank grey surface.  I heard the "Start Game" sound and then pressed "Stop 
Running".  Both Doukutsu windows remained open, so I closed Hourglass.

Next, I ran r64 and set print logging to "all".  I did the same thing as above. 
 This time, also, 2 instances of the game spawned, with each one asking me the 
compatibility mode question.  I pressed "Yes" to each one.  However, both were 
then stuck at frame 0 (with grey video and no sounds played) instead of 
running.  Here's the log for that attempt.

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 7:51

• Changed title: Cave Story issues (not VS2010 build issues)

Attachments:

• hourglasslog.txt

[GoogleCodeExporter]

Maybe it's unrelated, but I see fraps32.dll is somewhere in the callstack of 
all the crashes in that log. Could you try uninstalling fraps?

Original comment by nitsuja-@hotmail.com on 24 Jul 2011 at 9:04

[GoogleCodeExporter]

I uninstalled Fraps and attempted the same test as above.  This time, also, 2 
instances of the game spawned, with each one asking me the compatibility mode 
question.  I pressed "Yes" to each one.  "The game crashed." window appeared 
after the second question.

Immediately after, I closed Hourglass, ran it again, enabled logging, and did 
the same thing, then something different happened.  It asked me the 
compatibility question once, to which I answered "Yes".  Only 1 instance of the 
game spawned.  Then, it got stuck on frame 1 even though it wasn't paused.  The 
video was a blank grey surface.  Here's the log for that attempt.

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 9:26

Attachments:

• hourglasslog.txt

[GoogleCodeExporter]

And if that doesn't help, try setting 640x480 windowed mode in DoConfig.exe (in 
case your system doesn't support the 16-bit color conversion being attempted in 
fake fullscreen mode, or something like that).

Original comment by nitsuja-@hotmail.com on 24 Jul 2011 at 9:31

[GoogleCodeExporter]

That suggestion miraculously caused everything to work and the run to sync!  :O

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 9:35

[GoogleCodeExporter]

What's weird, though, is that I've played back this TAS with Hourglass in its 
windowed fullscreen mode before (though it had to be in the top-left of the 
screen to be visible).  I also had Fraps installed and running at that time 
(though that's probably unrelated).

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 9:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Can you verify that it also works in r63 (the VS2010 build)? And what's the 
latest build of Hourglass that works when fullscreen mode is set in 
DoConfig.exe?

Anyway, I guess the bug is that fake fullscreen mode doesn't work on some 
computers. I saw this on a Windows 7 machine once, where when I asked for the 
surface pixel format, DirectDraw reported the impossible format "16-bit 
RGB888", and various other DirectDraw functions such as GetDC failed. I 
suspected it was an issue with the video driver. Probably a certain amount of 
DirectDraw emulation will be necessary to fix this sort of bug.

Original comment by nitsuja-@hotmail.com on 24 Jul 2011 at 9:48

[GoogleCodeExporter]

I have verified that it also works in r63.  :)

I tried these revisions of Hourglass: r57, r39, r35, r11

In my test, r57 spawned 2 instances of the game and crashed.

r39 and below spawned a single instance of the game and run it with audio, but 
I saw just the grey surface.

I should mention that I recently plugged another monitor into my video card and 
I'm running a multi-monitor setup.  The second monitor is on the left.  When I 
was originally able to see the TAS in Hourglass' windowed fullscreen mode, I 
had only one monitor and the Doukutsu window had to be in the top-left of my 
screen because otherwise, the video inside the window was offset by double the 
distance from the absolute top-left of the screen, causing the video to be 
completely outside the window (and therefore not visible) if the window was 
dragged too far.

So, this time, I tried dragging the Doukutsu window to the top-left of that 
screen, but the video remained grey.  I dragged it all around both my screens 
(stopping dragging to allow the video to update in every new position) and the 
video remained grey.

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 10:08

[GoogleCodeExporter]

Note that the above tests with r57 and below were in response to "And what's 
the latest build of Hourglass that works when fullscreen mode is set in 
DoConfig.exe?"

I just unplugged my second monitor in order to test that, and the video was 
still grey.

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 10:12

[GoogleCodeExporter]

OH!  After unplugging my second monitor, I noticed my cursor could still move 
off my screen (to where the second monitor would be), so I went to Vista's 
display settings and found that monitor 2 was still shown there.  I unchecked 
"Extend my desktop to this monitor" and saved the settings.  I then tried 
Hourglass r39 again with fullscreen mode enabled in DoConfig.exe and Fullscreen 
disallowed in Hourglass, and it actually displayed video and ran the TAS!  :O  
It didn't even have that weird double-top-left-offset problem that I'd seen 
before.

Oh, wow, it even works in r63 the same as the above test in r39.  I guess it's 
related to having multiple monitors.

Original comment by lexlexlex@gmail.com on 24 Jul 2011 at 10:19

[GoogleCodeExporter]

By the way, it seems Fraps does cause desyncs too. That's not such a big deal 
because on Windows XP and Windows 7, Fraps is already automatically prevented 
from loading into the game, but that's not implemented yet on Vista 
(MyKiUserCallbackDispatcher will have to be reimplemented in an OS-independent 
way for that).

Original comment by nitsuja-@hotmail.com on 25 Jul 2011 at 7:39

[GoogleCodeExporter]

So, to sum up this issue:

-Dual monitors cause Cave Story's video to be blank grey if fullscreen is 
disallowed by Hourglass, but this can be worked around by switching Cave Story 
to windowed 640×480 mode in DoConfig.exe or simply disabling one of the 
monitors.

-This is unrelated to the VS2010 build, so Hourglass can continue to be built 
with VS2010.

-Fraps can cause Hourglass TAS desyncs on Vista (though I'm still not certain 
if that was the cause of the desync I saw in fullscreen mode).

-Multiple monitors might be the cause of Hourglass running Cave Story multiple 
times (sometimes?) upon pressing "Play".

Original comment by lexlexlex@gmail.com on 26 Jul 2011 at 4:46

[GoogleCodeExporter]

The Fraps causing desyncs on Vista thing might be fixed in r69. Or maybe that 
just broke everything instead, in which case, please let me know if r69 fails 
but r68 works for you (I've uploaded binaries of both versions).

The game starting twice is probably due to the code that automatically restarts 
the game with a different DLL loading order if it crashes before the first 
frame (this was implemented for the game RotateGear only), combined with issue 
11. I've since made the restart non-automatic (a dialog asks if that's what you 
want to do) so the running-twice problem probably doesn't happen anymore unless 
you specifically tell it to run again when that dialog appears.

Original comment by nitsuja-@hotmail.com on 26 Jul 2011 at 7:53

[GoogleCodeExporter]

Oh, and if you're checking r69 vs. r68 compatibility, try more games than just 
Cave Story if you can, since Cave Story has a tendency to work even when 
nothing else does.

Original comment by nitsuja-@hotmail.com on 26 Jul 2011 at 7:55

[GoogleCodeExporter]

For the record, before even reporting this issue, I tried (successfully) the 
following games in r63:

Syobon Action
I Wanna Be The Guy
Geoffrey The Fly
Warp

I'm busy this minute, but I'll try r68 and r69 soon.

Original comment by lexlexlex@gmail.com on 26 Jul 2011 at 8:37

[GoogleCodeExporter]

OK.  I just tested r68.  I have discovered something new.  I have one monitor 
running for all this testing.

At first, I had Fraps running.  I did the normal jtDoukutsu.wtf test with 
fullscreen disallowed in Hourglass.  It did that weird double-top-left-offset 
problem that I'd seen before.

I closed Fraps, then closed Hourglass and restarted it (because Hourglass never 
runs Cave Story a second time after it's been closed.  I'd report that, but 
it's relatively minor and probably hard to fix on all systems), then I did the 
same test and the weird double-top-left-offset problem was absent.  I tried 
this back and forth and it seemed Fraps running was the cause of that problem.  
It didn't cause a desync of the movie, however.  The test run proceeded as 
normal past the point I've seen it desync a bunch of times.

Original comment by lexlexlex@gmail.com on 26 Jul 2011 at 7:16

[GoogleCodeExporter]

r69 with Fraps running doesn't exhibit that weird double-top-left-offset 
problem.  :)  Testing more games with it now.

I tried the following games with r69 with Fraps running:

Syobon Action - worked perfectly (graphically and sync-wise)
I Wanna Be The Guy - worked perfectly (graphically and sync-wise)
Geoffrey The Fly - worked perfectly (graphically and sync-wise)
Warp - desynced in the first room (though the graphics were fine)

I closed Fraps and tried Warp in r69 again, and it synced and worked perfectly. 
 I opened Fraps again and tried again, and it desynced in the first room again. 
 I closed Fraps and tried again; same thing as before (no desync).  I think 
it's conclusive that running Fraps is causing a desync in Warp with r69.

I did the same testing pattern with r68.  It exhibited the same behavior with 
Warp and Fraps as r69.

I tried the following games with r68 with Fraps running:

Syobon Action - worked perfectly (graphically and sync-wise)
I Wanna Be The Guy - worked perfectly (graphically and sync-wise)
Geoffrey The Fly - worked perfectly (graphically and sync-wise)
Warp - desynced in the first room (though the graphics were fine)

Warp synced perfectly without Fraps running.

In conclusion:

-All my results with r68 and r69 were identical except for Cave Story, which 
fixed its graphical problem with Fraps running.

-Fraps had no effect on sync with Cave Story.

-Fraps caused a desync with Warp in both r68 and r69.

Original comment by lexlexlex@gmail.com on 26 Jul 2011 at 7:40

[GoogleCodeExporter]

Can I get logs of the following (in r69 only): Warp with Fraps, Warp without 
Fraps, (and less importantly) Cave Story with Fraps, and Cave Story without 
Fraps? (Stopping it after a second or so of gameplay should be fine.) Also, in 
which cases did you see the yellow FPS display of Fraps in the game window?

From what you're saying, it sounds like r69 successfully blocked Fraps from 
loading in Cave Story, but somehow failed to block Fraps from loading in Warp, 
which is weird because the thing that loads Fraps is a global mechanism so it 
shouldn't matter which game is running.

Cave story not running again until you restart Hourglass is issue 11.

Original comment by nitsuja-@hotmail.com on 27 Jul 2011 at 6:23

[GoogleCodeExporter]

By the way, about issue 11, I think someone reported it fixed (i.e. clicking 
Stop caused the game process to completely exit) on Vista in r15 or r18, but 
maybe it broke again later. It would be great if you could say report how it 
acts for you in those versions. If it was working and I can find out which 
version it stopped working in, it should be easy to fix.

Original comment by nitsuja-@hotmail.com on 27 Jul 2011 at 6:34

[GoogleCodeExporter]

I just discovered that if you have "Hide overlay" set in Fraps, it doesn't 
cause Warp to desync while Fraps is running.  This solves the mystery of how I 
was able to capture nitrogenesis' Warp TAS audio (and video, but I didn't use 
that part) with Fraps a couple weeks ago without a desync.

For my tests now, I'll have the Fraps overlay enabled for the Fraps tests and 
I'll close Fraps completely for the no-Fraps tests.

I've gotten logs of all 4 tests with r69.  Here they are.  In no cases did I 
see the yellow FPS display of Fraps in the game window, even when it was 
supposedly enabled.

As previously seen: Warp with Fraps enabled desynced and Cave Story with Fraps 
enabled did not desync.  Neither desynced with Fraps disabled.

Original comment by lexlexlex@gmail.com on 27 Jul 2011 at 1:42

Attachments:

• warp-fraps.txt
• warp-nofraps.txt
• doukutsu-hourglassr69logs.7z

[GoogleCodeExporter]

Regarding issue 11, I've responded there.

Original comment by lexlexlex@gmail.com on 27 Jul 2011 at 2:49

[GoogleCodeExporter]

OK, on my system I see this in warp:

000009CC: (f=0, t=6000) DllMain returned. (fdwReason = 0x16B4)
000016B4: (f=0, t=6000) PostDllMain called.

but on your system I see this:

00001DE0: (f=0, t=6000) DllMain returned. (fdwReason = 0x1D18)
[tons of other stuff that shouldn't be running yet, during which Fraps gets 
loaded]
00001D18: (f=0, t=6000) PostDllMain called.

This could easily cause desyncs besides Fraps (and other problems). So I guess 
I need to think of some way to guarantee that PostDllMain runs before the 
game's code starts running. Hopefully setting the thread priority really high 
will be enough, otherwise it could get difficult.

Original comment by nitsuja-@hotmail.com on 27 Jul 2011 at 4:08

[GoogleCodeExporter]

Could you test Warp with Fraps in r70? That case (desync with overlay on) 
should be fixed now.

The intended behavior is that things like Fraps are completely blocked from 
loading into the game because they could change how the game runs in arbitrary 
ways, and if you want to override that behavior you can enable the options in 
the "Runtime > DLL Loading" menu.

As for the multiple monitor issue, I guess I won't be able to look into that 
for a while.

Original comment by nitsuja-@hotmail.com on 30 Jul 2011 at 7:48

[GoogleCodeExporter]

I've switched to Windows 7 (and a new computer) since then, but I tested Warp 
with Fraps overlay enabled in r69 and it desynced, then tested the same with 
r71 and it didn't desync.  So, it looks like your fix worked.  :)

Oh, actually, I just noticed something important.  The difference between the 
two revisions seems to be that "Allow loading any custom/installed DLLs" is 
checked (enabled) by default in r69 and unchecked (disabled) by default in r71. 
 Enabling that option in r71 with Fraps overlay enabled causes Warp (and Cave 
Story!) to desync.  Disabling it causes them to sync again.  I see!  I guess 
that should be kept in mind for anyone who has Fraps and wants to make a TAS.  
If they make it with that option enabled, they risk making a screwy input video.

Original comment by lexlexlex@gmail.com on 1 Aug 2011 at 8:21