Musings on the Cosmo Observatory and similar crash scenes

[Goku7]

This is a train of thought I had earliear today on the subject.  Now, seeing as how I've only read about the crashes and never experienced them myself, I'm guessing I may have missed a few facets of these inexplicable bugs, and in that case, point 'em out.  Or, if you think you see a promising angle on a feasible solution/explanation, point it out.

Now, to begin:

We know the usual suspects for movie scene crashes -- improper codecs, bad/corrupt CDs, bad/corrupt optical drives, etc. These standard solutions sometimes don't work, and its frustrating when that happens.

And the more I think about it, the more I suspect that the Cosmo observatory, Junon Elevator, and (in roastbeefsally's case) Cloud's Mind crash scenes when the normal solutions have proven to be ineffective, are manifesting due to some incompatibility between the video card drivers, XP, and the way DX5 handled scenes with both 3D models and an FMV playing simultaneously.  Think about it for a second -- nearly every major movie crash scene has an instance of in-game models being drawn on top of the movie. Direct3D and DirectShow routines are more or less being run simultaneously.

It's as if DirectShow5 and Direct3D5 are fighting for primary (and possibly exclusive) control of the primarly drawing surface, or are trying to cooperate in a way that uses the hardware at a level which the newer WinNT kernal forbids (think along the lines of old-school techniques like Direct Hardware Access that are no-no for windows NT).

Now, there may be another angle -- from what I've seen, very little PC games these days try to use movie playback as a background to render 3D objects on top of, let alone animate them.  If anything, its either movie playback, or 3D rendering, but not both simultaneously.  Perhaps graphics driver programmers, upon following the trend away from simultaneous movie playback + 3D rendering scenario's in games, have decided to phase out a significant amount of support for doing it?

And then, finally, there's the whole thing about DX5 code being looked on as uber-legacy programming from the modern driver-developer's perspective these days.  I highly doubt that they are concerned with keeping 100% support for old DX5 programming routines, so their drivers may have acculmulated an FF7-killing bug here or there that may be indirectly caused by whatever generic legacy support for DX5 routines they have programmed in.

[EmperorSteele]

Hmm..

I dunno.  I have to raise doubts about this theroy, as, while I'm running a 6600gt and do not come upon this crash.

Also, if this were true, people's games would crash on the elevator ride up into the observatory, not while in the observatory itself.

I'm using a 6600gt, and while i'd love to test your theory, i dont have any save points near cosmo canyon.  However, i know i can play other sprites over fmvs scenes just fine. (clouds mind and northern cave, for instance)

[JPWest]

I don't think it's a matter of hardware... as I had the Cosmo crash on my PS copy...

[Threesixty]

I never had those crashes either... I did have a few movie crashes and sound that I can remember. Let's see...one was the dolphin splash sound, and the other was when all the weapons were released......but they were both related to sound. Putting the Direct Sound Accleration into Basic mode, would get me thru. I think I had a problem with the sub mini-game, once too.... Same soluiton.

I did have once instance where all the movies were pausing.... I removed all the Video and Audio Codecs, from Windows.... And it solved that problem. All these Crashes were with Win98SE...with a SBlive card. Creative quit updating drivers for Win98 after DirectX 7 or something.

I think it's a software conflict of some sort... If I had a computer that had the problem...I'd probably be able to figure it out. The solution might end up being:  C:\\Format C: , though.

[Goku7]

Hmm..

I dunno.  I have to raise doubts about this theroy, as, while I'm running a 6600gt and do not come upon this crash.

Also, if this were true, people's games would crash on the elevator ride up into the observatory, not while in the observatory itself.

I'm using a 6600gt, and while i'd love to test your theory, i dont have any save points near cosmo canyon.  However, i know i can play other sprites over fmvs scenes just fine. (clouds mind and northern cave, for instance)

Well, we also need more information on the configuration of the systems in which these crashes are manifesting themselves.  This would include normal system specs, drivers used, what version of Duck Trumotion you're using (original or patched codec), full or standard install (perhaps the actual game script -- not the movie file -- for that section is corrupt on the install CD or game CDs; it could account for the apparant randomness in who gets victemized by it, while simultaneously allowing for the fact that no amount of reinstalls will solve the problem), and any sort of compatibility mode you're running the game in.

There HAS to be at least one single point of commonality out there that could lead to a pattern that's buried in the apparant randomness of it all.  For all we know, there could be a higher percentage of corrupt discs out there than we thought -- most of the time we think that the only part of the disk that tends to be corrupted is the movies, but if the script that calls up for that movie was not copied properly, that could crash the game too.

Finally, it's not just a hardware thing that's being theorized -- its also the mentality of the programmer who wrote the code.  Keep in mind that this game was designed to operate in the Win9x environment, and as such there the programmers may have used a few speed-increasing tricks that are illegal to the point of crashing in the WinNT-2000-XP environment.  The Chocobo Race crash is one instance of this, as the memory space it tried to use was no good in 2000/XP but worked under 9x.

I don't think it's a matter of hardware... as I had the Cosmo crash on my PS copy...

Maybe, maybe not.  Has it crashed on the console itself?  Or are we talking about it crashing when playing it on an emulator -- if its the latter, then ultimately the computer is being told to do the same thing as it would have been told to do in the PC version, and crash.

If its the former....it could be that the mass production facilities for the PS1 version's CDs also had random corrupted copies being produced, with the corruption either affecting the script which calls up the movie or the movie itself  -- and that, in turn, could be more evidence that the random flaw in the copy process was not caught before they started mass production of the PC version's CDs.

[EmperorSteele]

Well, i have found that some movies are physically located on parts of the discs that are harder to read; I recall when i first got the game, junon.avi and biglight.avi would NOT play unless I played them in Windows first.  This problem was eleviated when i got a better cddrive, however =/

[Goku7]

Right, but if the script that goes along with the movie is in some way corrupt, that in itself is enough to either lockup or crash FF7.  For all we know, all we need is to do some sort of file integrity check between one who has the crash and one who doesn't, and if there are obvious integrity differencies (like, getting different checksum results from the two), then curing the problem could be as simple as grabbing the "good" copy of the script files and replacing the damaged one with it.

[RPGillespie]

Or are we talking about it crashing when playing it on an emulator

Yeah, my friend said his crashed on ePSXe, but luckily I have the real PC version.

[Contra]

I don't know if this could help at all, but I had some problems with a certain movie/3d scene on the PSX version. On a real playstation, not emulated. About 90% of the time, since I bought the game, my PSX version crashes while trying to play (What the PC version calls) Wh2e2.avi. That's the flashback with Aeris at the City of the Ancients.

I just thought I'd mention.

[Goku7]

...which files contain the script for the scenes in which these crashes are occuring?

I've never run into ANY crash scene in any of my playthroughs of the PC version, so if there's a chance that there IS a random flaw in the file's integrity which causes the crash, perhaps using the files from my apparantly "good" copy might alleviate the problem?


I mean, come on.  We've recieved how many reports over the years of disks with corrupted movies?  They just seem far too common to think that it's impossible that the rate of corruption during mass production is that high.

Still, if we could get any data on what's in the RAM at the time of the crash, and use some sort of memory breakpoint thing like Jedwin did when he pinpointed the cause of the Chocobo Crash, we might be able to narrow down the location of the offending instruction(s).

Either way, I wanna know which files are involved -- I wanna my "corrupted script" theory out.