Messages

126

Scripting and Reverse Engineering / Musings on the Cosmo Observatory and similar crash scenes

« on: 2005-05-25 06:22:48 »

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.

127

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-25 05:16:05 »

Do you know which one exactly? I randomly tried the flevel file but to no avail.

If I remember right, I think it was in the WM folder, the file in question being "wm.lgp".  I seem to recall the World Map part of the Field Model Hand Patch being applied wm.lgp, so logically....

well he has done models for the soldiers so i presume he'll do model's for hojo and them

Speaking of Hojo, I think he presents possibly the perfect first test of using an existing battle > field conversion as a templete to edit -- his battle model has green skin, so we'd need to change the vertex color values to a skin tone after the conversion to the field format.

Once we can successfuly do that, it shouldn't be too hard to make a similar model for Professor Gast from the new Hojo -- and a Heidegger model could be spawned by a vertex color edit and decapitation of Palmer's model followed by a surgical attachment of the "stock" Heidegger's head.

I don't recall what "polensalta" looks like, but if that doesn't work out for Scarlet, perhaps Elena's model will work with some hair transplants from "stock" Scarlet.....

The list of ideas goes on..... :wicked:

128

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-23 23:48:32 »

The data for the world map characters is in a different LGP file, if I remember correctly.

But the problem is that there are LOTS of NPCs and very few people interested in rebuilding them.

Well, you COULD just resize the existing polys....

129

Archive / Mod/File locations

« on: 2005-05-22 08:36:51 »

I think I saw that Useful Links Topic thread still stickied in Game Tweaking....lest we forget all those links.

Ironically I was working on a file repository part of the site a while back... to be integrated into these forums, somewhat (shared user database and whatnot). Maybe I should actually get around to finishing it.

If you don't mind me asking, would this be related in any way to the latent "attach to post" ability these PHP-type forums are supposed to have, or are we talkin' about something more akin to Mirex' Trash bin here?

130

Scripting and Reverse Engineering / Mideel Lifestream Crash

« on: 2005-05-22 08:17:51 »

File this one under "Random Shot in the Dark Suggestion", but have you considered the possibility that whatever "tweak" you applied to get past the Cosmo Canyon crash has somehow caused the game give you your current crash problem here?

131

Archive / FF7 PS3 Tech Demo over opening .avi

« on: 2005-05-22 08:13:57 »

Well, then.....I stand corrected.

Carry on with your plans for world domination--er, I mean movie modification. :wicked:

132

Archive / FF7 PS3 Tech Demo over opening .avi

« on: 2005-05-20 22:39:36 »

I could have sworn that everybody else here has documented that FF7's movie code could ONLY interface with the duck truemotion codec, causing attempts to cleanup and recompress the movies using DivX or something to be useless.

If what you say is true.....then why haven't the other people here try to take advantage of it for all this time?

133

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-20 22:33:32 »

The stuff Reunion released only contains lighting-corrected models for Cloud and the Shinra soldiers, as far as I know.  We'll have to wait for him to release the rest when he gets around to it.

134

Archive / FF7 PS3 Tech Demo over opening .avi

« on: 2005-05-20 04:20:26 »

LOL...the ideas I give people sometimes.....

Pardon me if I'm missing the obvious here, but exactly where in your instructions does the fact that FF7 will only do in-game movie playback for files that are compressed with the Duck Trumotion codec come into play?

And something else just occured to me....isn't there a good 7-10 second shortage between this movie and the original intro movie, which just might be enough to confuse FF7 a bit?

135

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-19 21:08:03 »

Zero knowledge of how the files manage to store 3D animation data as mere text, and the tiny little fact that I can't draw or model worth jack -- that's what.

136

General Discussion / This is what FF7 will look like for PS3

« on: 2005-05-19 05:32:00 »

Even then, I don't think they'd make a new PC version.  And because of that, if/when they release a remake, we'd just grab any pre-rendered backgrounds and use them for the ones we have now, and grab anything else that could be imported or converted.....  :wicked:

137

Troubleshooting / yet another cosmo canyon crash

« on: 2005-05-18 21:17:21 »

You know, with the apparant frequency that this problem rears its head, perhaps it would be wise to incorporate a feature into Jenova (or any other editor, or heck, a completely new program) that allows one to advance his save file past the lockup, so that he won't necessarily need to go track down someone who can get past it for him.

Now, I've never used any FF7 save editors, but I guess something like that is already possible, but what I'm going for here is some sort of scripted hacking sequence for these specific portions of the game that are crash-prone.  Like, a dialog box asking you which problem area you' like to advance your save past, and it'll automatically do the edits.

138

Archive / FF7 (hangs strangely after intro)

« on: 2005-05-18 21:11:57 »

Ah-HA!!!

I just realized how to get around that.  If I'm right, the file named "FF7input.cfg" should store the control mappings.  Now, it doesn't appear to be edit-able in Wordpad or Notepad, but it might be possible for someone who can remap the controls in-game to do so, and then send their re-configured FF7input.cfg to flaredenton, who could then overwrite the one he has.

Logically, this should work... :wicked:

139

Archive / FF7 Window Colors?

« on: 2005-05-18 19:37:33 »

He can't, because FF7 changes window color by using specific RGB color values for each of the four corners, and the default color is actually a color gradiant that changes color slightly as it goes from the upper left to lower right.

If he were to simply change it to blue, he'd get a mere FLAT blue color, which is NOT what the default menu color is.

140

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-18 00:26:32 »

I just thought of something.  Reunion, is it within your capability to have Cloud's hands be rotated 90 degrees during the crawling or ladder-climbing animations?

Sorry Goku7, but I think I can't do a battle->field conversion program. Mainly because I don't know how to generate the normals automatically (well, neither manually in fact). Besides, acording to what Reunion said, there is also some rearragement work to do on the files (If I din't missundestood him) and I don't know how to do this either.

Darn. Well, one always hopes....

141

Archive / FF7 (hangs strangely after intro)

« on: 2005-05-17 22:54:43 »

Windows2000 is the first culprit I'd look into.  FF7 absolutely HATES that version of windows for reasons only God knows why, and from what I understand, sometimes will run wonderfully on one system and crash on another, even if the systems appear to have identical setups -- it's like it's compatibility is being governed by the Heisenberg Uncertainty Principle or something. -_-

At any rate, I'd recommend you consider running it on another version of windows (either 98 or XP), provided you are able to do that inexpensively.

-edit-
Actually, scratch what I said about blaming Win2000 first.  If the control setup isn't the problem, then move on to blaming Win2000.

142

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-15 23:40:09 »

About what Goku7 said, I think he is right. I've been thinking about several characters that could be redone using parts of other battle models. But doing things like changing the colors and resizing the models manually would be boring. That's why i'm working on a little proram to do some of this stuff easier.

Thanks for the support.  And if this little program you're working on is going to be capable of resizing the models, have you considered you might be able to use it to automate the process of converting models from battle > field, to help Reunion?

However, I think converting all those models would be a very heavy job for Reunion alone. If there was some more people working on this, It wouldn't be senseless to think on a full set of models replacement. Or that's what I think, at least.

I would try to help him with the conversions, but I'm afraid that I have no skill in the way of drawing or modeling at all.  What I CAN do, though, is provide a delivery system for any upcoming releases that doesn't require LGPTools -- providing that DagSverre doesn't have any objections to getting his program involved in this project....

What program, you ask?  Dag's Patchmaker program.  Since it runs on a difference engine, we can simply let it analyze the differences between the original Char.lgp and the modified char.LGP, and create an executable patch that will modify the original LGP to make it contain the new data of the modified LGP.  Since we can't use an FFpatch to do this (because Reunion's modfication adds completely new files to the LGP archive, and FFpatch doesn't record such changes), and since not everyone seems to have success with Centra patching, using Dag's Patchmaker might be the only solution at this time.

Oh, I've been thinking how would look like a hi-res SD model. And ...
http://i6.photobucket.com/albums/y231/usebio/SD_CLOUD.jpg


I think this could be a solution for the clipping poblems produced by the difference between the size of the original and the hi-res models.
Actually, this model is still a bit taller than the original SD one (it's about 1.5 times smaller than the hi-res model) and thus it doesn't fit perfectly on the background (but has a few less clipping problems).

I know that Cloud has had ego issues in the past, but......this is the first time he's shown physical symptoms of Big Head Syndrome!

All joking aside, I think I agree with EmperorSteele said (on page 3) in that it would be counterproductive for Reunion to consider the SD-model approach as the only solution, since he's already spent so much time working out the bugs with the non-SD approach.

That being said, I think the reason why Borde's SD-model doesn't have as many clipping problems as the non-SD model, is simply because the SD model's legs are smaller, and happen to match up with the original model's leg length, so that alignment with the background had been preserved.

143

Scripting and Reverse Engineering / FF7 Problem

« on: 2005-05-15 21:25:56 »

It's sounds like a video codec issue.  You can install the necessary codec off the Install Disc by putting it in the drive, and selecting "Install DirectShow" from the Autorun menu that pops up.

The 1.02 patch (aka the TNT patch) will work with both ATi and nVidia cards.  It's really been misnamed, because it deals more with simply removing the 8-bit paletted texture requirement than adding nVidia-specific code.

At that point, if it still doesn't work, try using different compatibility modes (right-click on icon > select Properties > choose a compatibility mode from the compatibility tab) and see if that clears up the problem.

144

Releases / Battle model > Field model Conversion FINALLY!!

« on: 2005-05-15 05:00:18 »

I was thinking....after all the characters who already have battle models are implemented (presuming that you are going to try to do every last one), perhaps we may be able to make ones for the npcs by using one of the existing battle model conversions as a template, and changing the colors of stuff like clothes, hair, modifiying bone structures, polys/verts, etc. to make a suitable imitation of them, while still staying within the limits of what FF7 can support of in a model?

Ok, I'll admit that sounds like a lot of individual models to do.  But take a step back and think about this for a second: from what I can tell, there are only a few "generic" looking npc models that are seen in most towns in large numbers (I.E., like 4 or 5 models are responsible for the majority of the game's npc population), and therefore modifiying a few existing battle model conversions to cover those, er, "classes" of npc could cover, like 78% of the npc's in the game.

145

Archive / Out of Memory

« on: 2005-05-15 04:47:21 »

That's right.  I've made mistakes involving memory allocations and loops before... you can run out of memory real fast.

Heh.  Back when I was working on the Final for my introductory C++ class, we (me plus two others, it was a group project) had to figure out a way to set aside and allocate memory space for the initial five or six "database" entries for a very basic name/address/telephone type of thing, AND since we had it load the entire database into memory to allow the user to manipulate it prior to saving any new info to a file, we had to have it dynamically allocate and release additional memory, creating new variables on the fly, destroying them when they weren't needed....

...and as a result we had some funny, program-crashing, system-beeping bugs during testing because any one of us would keep messing it up accidentally.    I could only imagine the difficulty in trying to do all that allocating manually through ASM.... :erm:

146

Archive / Out of Memory

« on: 2005-05-14 23:44:57 »

If its a memory leak, then the best thing you can do is to try to bring it to the attention of the people/person who wrote the program and have them fix it, as memory leaks are usually a case of the programmer's code not totally releasing all the memory he's dynamically allocating when he wrote it....at least that's what I understand of how memory leaks are created.

...Well, I suppose the only OTHER way to solve it would be to reverse-compile the program or get the source code and fix it yourself, but.....

147

Troubleshooting / FF7 problems with XP

« on: 2005-05-14 01:34:09 »

Ah.....it ALL makes sense now.....

148

Troubleshooting / FF7 problems with XP

« on: 2005-05-13 22:45:03 »

(Actually... I think the slowest Athlon 64s are 1.8 GHz, but I had a similar problem using the MS synth on a Pentium 4, and it turned out it happened when the CPU was downclocked because it wasn't being used fully -- Athlon 64s can do that too.)

Waitaminute.....P4's are only supposed to downclock themselves if they are in danger of overheating.  If the processor isn't doing much, it should not be downclocking itself at all, since the load is so light.

149

Archive / Hi, New to the forum, got some questions =)

« on: 2005-05-12 19:54:41 »

From what I understand, the company allowed Square to bundle a type of consumer-use-only version of their codec that can only decompress the info but not compress it.  I have no clue how they did that, but I think there might be older "developer" version floating out there on the internet that can do both encoding and decoding.

At any rate, I think one thing we can all agree on is that the movie-playing code of the FF7 engine needs an overhaul.

150

Archive / Hi, New to the forum, got some questions =)

« on: 2005-05-12 00:59:44 »

And hey, goku's pimpin my site.  Ooooh yeah *cool*

LOL.   It's not just me, either.  The guys on the FF7pc board over at GameFAQs also regularly link to your site when someone asks where to find the various mods and patches for the game.  It's what happens when someone gets smart and hosts such a compiliation all in one place that's easy to get to.

At least they should improve on the existing models, you see the screenshot of cloud? his two arms and hands all raised up acting all tough and make him look really stupid and retarded, should make him so his hands and arms doesnt raise up like that

I see your point, however that is probably something that will be addressed down the road.  The stuff that's been accomplished is more akin to taking our first experimental baby-steps than anything else.  We succeeded in the basic concept (putting "hi-res" battle model of cloud on the field screen and making it walk around without crashing the game), and it will probably be followed by getting the other characters' battle models on the field and walking around, AND THEN, once we're satisfied that the current modifications are working properly, we'll be able to focus on improving the existing models and animations.

there are alot of improvements you can make for pc versions but then somebody should put together a package with everything in it,

I agree that that would be a good idea, but I think right now it might be best to wait until we've gotten things a bit more polished and sorted out, as well as permission from each of the different authors of the different patches and mods to bundle everything together -- and that's not even considering what type of delievery system to wrap it all up in, that won't require third-party utilities such as Ficedula's "LGPTools" program to install them.

...like rip the movie from psx and put in pc, thats a good idea, makes it less pixelated and stuff,

Unfortunately, that won't work.  The movies (with the exception of the Eidos logo, obviously) already provided in the PC version are already direct conversions from the PSX version, right down to the base resolution of the video, if I remember correctly.  The only things Square changed before converting them is that they added the PSX version's music to the opening and ending movies as a direct audio component.

The relative ugliness of the PC movies is due to 3 things:

1.) The limitation of 16-bit color depth is causing major dithering to take place.  If someone can get that 32-bit color patch to work without messing up the game in any way, we could get PSX-like color quality from the movies.

2.) As you probably know, taking a 320x240 res movie and stretching it to full screen at 640x480 can result in some major pixelation.  Now, that might not be so bad, except...

3.) The FF7 engine is not even trying to do any sort of video filtering AT ALL.

On top of all that, FF7 can only use the "Duck Truemotion" codec to read the movies.  Compressing them with a better codec or something will only result in FF7 refusing to read them.  So, if you were to rip the PSX movies and encode them so that FF7 can play them, you'd wind up back where you started.

Until it's possible to mod the engine to run in 32-bit color or apply image filtering to movies, using the PSX movies are a moot point.