Qhimm.com Forums
Miscellaneous Forums => Archive => Topic started by: amadeus06 on 2005-08-10 16:43:14
-
Hmm i dunno what to do, i have all the patches i tried running it in many different ways and so far i havent had any problems. Everything is going A-ok. but once im trying to escape the shinra and i enter the motorcycle bike chase my game crashes. It accually last for a good 10 secs before it compleatly crashes.
Also when im moving around in my bike i seem to be going to fast like if the game was being accelarated. but i dunt know how to fix it. Can anyone help?
Mod Edit: Moved to Game Tweaking
-
I reached this point of the game, and had actually run into the same problem. It went insanely fast but I somehow managed to make it through to the boss.
An error message I did not get though. What did it say?
-
I've just got to the bike race part too, which gave the same results as Veclord.
It went through very quickly, so all my characters were pretty much wasted by the time the boss appeared.
No crash either.
-
As for the speed problem:
Turn on VSynch =) To do this, go to your desktop,, right-click, hit "properties". Go to "settings". Hit "Advanced". Look around for your video cards software tab and under "performance settings" look for "Vsynch" or "Wait for vertical synch" and turn that ON. Then click the "monitor" tab and set teh refresh rate to 60htz if at all possible
Note that, in normal Windows, 60htz will hurt your eyes after a while, so make sure to revert it back to 75 or 80 or whatever the default is.
As fort he crash, hmm, you do hae a full, LEGAL copy, dont you? Pirated versions tend to have crashes liket hsi, and there isn't anything we can do to help.
-
It is a legal copy i just spend 62 bunks on it on ebay.
I still cant fix the problem. I've done the scene several times and i just cant do it. It never crashes at the same moment, on one of my attempts i was able to play for about 30 secs before i got this message.
http://img.photobucket.com/albums/v478/amadeusaau/d2675732.jpg
I know its the usual for most programs... PLZ HELP I WANNA FINISH THE GAME B4 ADVENT COMES OUT
-
So you've already tried it in software mode.?
That fixed all my weird problems..
-
I can't guarantee it, and I don't know if you've tried it but you could attempt to run the game in compatibility mode.
Navigate to your FF7 directory and right click on "ff7" (the file with the blue comet). Click properties. A window will pop up and you should see 3 tabs. General, Compatibility, and Summary. Click the compatibility tab. Under that, you'll see a checkbox that says "Run this program in compatibility mode for:". Check this box, then select Windows 98/ME from the dropdown box. Click apply, then try it out again. Like I said it's a long shot, but worth a try.
It's sort of an irrelevant note but I did find out that the speed issue also happens during the chocobo races.
Anyway you should also make sure you've updated your game to 1.02. If you haven't, now is a good time to do it. Check out my tutorial, and the compilation listing in this category of the board to get the link.
-
It is a legal copy i just spend 62 bunks on it on ebay.
I still cant fix the problem. I've done the scene several times and i just cant do it. It never crashes at the same moment, on one of my attempts i was able to play for about 30 secs before i got this message.
http://img.photobucket.com/albums/v478/amadeusaau/d2675732.jpg
I know its the usual for most programs... PLZ HELP I WANNA FINISH THE GAME B4 ADVENT COMES OUT
Maybe you can find an old set of savegames for FF7 which are taken at various point in the game, so you can skip ahead a little or ask someone here for a save-game after the part where it crashes.
P.S. FF7: Advent Children Limited Edition comes with a special International Edition of FF7 for PSX/PS2.
-
First, I cant seem to use software mode either, my PC restarts when ever i attemp to play in it.
Second, I have been playing in 98/me through out the game, i did this to fix a past problem.
Third, hmm maybe somebody can play my saved game across this, fight the boss and save then return my save file back.
http://us.f2.yahoofs.com/bc/3fff64e1_140b2/bc/My+Documents/save.ff7?BCd.n.CBaQ7DRUA_
If anybody can do that for me i really apreciate it
-
I'm in the game right now so I wouldn't mind. I can't access your link though. You could try emailing it to me: [email protected]
-
kk i sent it
-
Done. If you get to another part with the same crap just let me know and I'll do the same thing again.
I also didn't remember how you had your materia set up, so I just set it up to beat the boss then took it off on everyone before I saved so you could change it back to how you had it.
Barret learned Mindblow after I beat Motor Ball. :o
By the way Emporer, the Vsync trick didn't work for me. It blasted through the mini game just like it did on my file.
-
alright thx a lot.
While u where playing my file, i uninstalled all my FFVII files and installed it back up with only the 1.02 patch. I got through the race but when i reeched the boss my game froze, so i installed the movie patch and tried again, finally it worked and i got through the fight and everything.
Then i got ur email.... so yeah thx for the help, even tho i figured it out myself in the end.
It seems like the choco patch was the culprint in this scenario. perhaps ill try installing the chocopatch and see if it crashes again.
Yeah if i come into more trouble ill be sure to email you, u've been plenty help.
-
As far as I know the 1.02 patch contains the chocobo patch anyway, so that might've been what was messing it up.
-
I'm not too sure. In my case I had to install the chocobo patch seperately.
-
As far as I know the 1.02 patch contains the chocobo patch anyway, so that might've been what was messing it up.
This is not true. You must apply the Chocobo patch after the 1.02 patch.
-
By the way Emporer, the Vsync trick didn't work for me. It blasted through the mini game just like it did on my file.
did you set your monitor for 60 hertz? Cuz otherwise you're looking at 75-85 frames per second.
-
I was sure I had it set to 60 hz since I remember changing it back to 85 afterwards.
Why in the hell does it only happen on those two parts though? Wouldn't the entire game typically run quick like that?
-
Why in the hell does it only happen on those two parts though? Wouldn't the entire game typically run quick like that?
It what happens when a bad programmer does not use delta time(equal to how long it takes to process one game frame/loop) to times all movement/animations by. The mini game is programmed seperately to the main game so it only affects it. If delta time was used then it wouldn't make any difference how many fps the game was getting as everything would still go the correct speed.
note: deltatime has many different names it just what ive been taught to call it. deltaTime = clockTime - PrevClockTime
-
It's probably a question beyond most of us, but wouldn't there be a way to disassemble ff7.exe and dig through the coding and implement something like this? I'm not a programmer, but I do know that most languages are different in their own way. What language was FF7 written in?
-
It's probably a question beyond most of us, but wouldn't there be a way to disassemble ff7.exe and dig through the coding and implement something like this?
Trust me, that's not you want to do. It's far more work than you can imagine.
Also, I believe the game does run faster at other parts as well, it's just that in an ATB, or a cut-scene it actually has to wait for the user's input, so it's not too obvious.
-
I dont know much on things like this because im no hacker/cracker/decrypter but i do know that most programs are incrypted to prevent exactly what you are talking about. The guy that used to live next door to me develops app for small businesses and used to do this to prevent the reverse engineering of his apps.
I would say its pretty impossible to do without the source code. With the source code it is a fairly simple thing to do.
--- Doh you beat me to it.. sorry
-
Well I know it's not completely impossible. This is a relatively old game and I see people upload "no-cd" patches for every game on the market no matter how new or complicated its protection is. Something else that bothers me about it is that, well, think of the guy who created the chocobo patch. He knew the programming enough to know what to change in order to resolve the problem.
I'd like to take the opportunity to learn basic assembly code, and hopefully fix some of the game's smaller problems. I know it sounds so far fetched but I love this game, and I'd leap at the opportunity to learn how it works. That's what I love so much about this board; you are taking the initiative to fix and improve something that Square won't. What Reunion did with the models was something I dreamed of playing this game as a kid. To know that with determination that things like that can be done - It astounds me.
-
The difference in difficulty:
Makeing No CD crack = like riding a bicycle if you know how to do it you can.
Implementing DT after source has been compressed & encryted = is like riding a bycle with broken legs and arms while been blindfolded on a busy highway.
well thats just my opionion.. on the other hand the more i think about it the more i think it could be done. If it is possible to NULL a variable or command like what they did with the chocobo patch then why shouldn't you be able to divide one varible by another, you would need to find the correct varible first. And also im pretty sure the filesize cannot exceed the original as sometimes games check for this.
by the way the im a bit like you, im here to learn more about this sortof stuff so ill be looking into this some more if i get the time.
-
But in the ChochoboPatch (I know it sounds like "omg another $%#^" that tries to be a hacker, and the only thing he did, is reading about "how it has been done") NOP-ing some command actually worked, because it prevented the game from crashing.
When talking about something that SHOULD be done (frame rate control) but wasn't implemented, you have to realize that it would be more difficult to modify. Although modifying the ff7.exe isn't so hard (game doesn't check the size of the file, isn't encrypted or so...) it is really hard to find out how to do it, so the mini-game would work correctly...
And the assembler isn't hard at all, you have to know few opcodes... nothing else... :P
dziugo
-
This is probably a stupid question but would anyone think it'd be even REMOTELY possible to take the programming from the frame limiter in GTA3, translate it, then somehow add that technology into FF7 around the mini game scenes? I know it'd be anything but easy (especially since they're both completely different games) but it would at least force the mini games to run at a set frame.
If this weren't possible (which is pretty likely), does anyone know of a programming value that would allow us to do something similar?
-
(...)the frame limiter in GTA3(...)
:o Why from the GTA3?
The only thing that need to be done is counting frames and pausing for a little moment if it's needed (since there already is a real-time clock ticking all the time)... But to do that, the information about handling the mini-games by the ff7 would be needed...
Nice idea though...
-
This is probably a stupid question but would anyone think it'd be even REMOTELY possible to take the programming from the frame limiter in GTA3, translate it, then somehow add that technology into FF7 around the mini game scenes? I know it'd be anything but easy (especially since they're both completely different games) but it would at least force the mini games to run at a set frame.
If this weren't possible (which is pretty likely), does anyone know of a programming value that would allow us to do something similar?
way ahead of you, i disasembled one of my own programs to help me know what to look within the FF7.exe.
This is part of what is used to calculate the deltaTime withing the mini submarine game( as indicated the the call to time get time). of coarse there more than this too it, ill post more about this later.
:0077DA90 C7052070980000000000 mov dword[00987020], 00000000
:0077DA9A FF1574637B00 call dword[007B6374 ->003B92E2 timeGetTime]
;;call WINMM.timeGetTime
---------------------------------- EDIT / ADD --------------------------------------------
// sorry i didn't post the rest of this earlier i had to go out.
How deltaTime works mathimatically is by, say the bike needs to move 100 units a sec, and your currently getting 60fps a sec. if you then divide 100u / 60f this gives you 1.666, 1.666 is then how much the bikes position needs to move each time each time the frame is updated to provide smooth movement over that second.
To calculate this each turn you call timeGetTime() and then subtract the previous value of timeGetTime() from it, this leaves you with a value of 0.015 or something equally small, you then times every bike/animation movement value by this value (value changes each update depending on how fast your pc is processing the frames) and vola you now have a consistently moving vehicle no matter what fps you are getting.
- so to sum up MOVEMENT * TimeBetweenFrames(otherwise know as deltaTime). and thats it.
Im seriously thinking about trying to implement some this into the motor bike game after discussing this over this forum however there are some issues.
- dissasembled programs take up many pages (1000's upon 1000's pages) this makes it very hard to find the values needed to be changed, the sub mini game was clearly marked out, however none of the other mini games seem to be, as far as i can tell.
- although i know a fair amount about games programming, i know next to nothing about dissasembly and assembly programs / programming so i will probely purchase some learning books about this. ( I wish the guy still lived next door he recently hired an expert at this type of programming to help him to secure his programs created in c++.net, it would've helped a great deal.)
- Also basically I need help with this :D .
If someone else understands what i was talking about with dT as has the abilities to implement it, please do.. i would greatly apreciate it.
The only thing that need to be done is counting frames and pausing for a little moment if it's needed (since there already is a real-time clock ticking all the time)... But to do that, the information about handling the mini-games by the ff7 would be needed...
This does not work, it results in very jerky movement (ive seen someone try it before). Thats why dT was invented. Movement in games is nothing but an illusion. when a game updates each frame it simply tells the gfx card to place the 3D object in another location based on coordinates calculated by the velocicity (a normalized vector in direction the object needs to move - usually) if the velocity is a set velocity then the faster the frames are updated the faster it will move position. different frames will allways process at different speeds so if you pause after each frame it will pause "After" different amounts of time. As you can proberly tell this is very hard to explain just how much this affects the gameplay with words alone but heres an attempt anyway.
e.g 1.
frame 1 , time taken to process = .15 sec
pause for 0.10 sec
frame 2 , time taken to process = .15 sec
pause for 0.10 sec
frame 3 , time taken to process = .15 sec
pause for 0.10 sec
overall time to display those three frames is = to 0.75 secs for those three frame's. now what happens if some frames took longer to process because of the graphical content on screen.
e.g 2.
frame 1 , time taken to process = .15 sec
pause 0.10 sec
frame 2 , time taken to process = .25 sec
pause 0.10 sec
frame 3 , time taken to process = .20 sec
pause 0.10 sec
all of a sudden the overall time to display those three frames on screen becomes = to 0.90 secs, so to display 60 frame it will take 18 seconds one time where as in the first eg it will only take 15 seconds to display the 60 frames. thus this results in very jerky movement as no two frames in a game are ever processed in the same amount of time.
I hope this clears this up for you's. If you want a quick & dirty solution you can enable vsysn with 60hz refresh rate, this will give you a fairly consistant frame rate of 60fps, and then half every movement value this will then simulate 30fps. but its a pretty shitty way to do it. by the way i hope someone actually bothers to read all this it took a bloody hour to write not that i mind i was just going to play games anyway.
-
The only thing that need to be done is counting frames and pausing for a little moment if it's needed (since there already is a real-time clock ticking all the time)(...)
This does not work, it results in very jerky movement (...)
It won't if it's done correctly. Pausing after each frame would be needed (not every second or sth...)
It took me some time to understand the dT-thing. Cool idea but... Isn't it, that movement of every single unit in game should be affected by this?
It should work anyway. As for the disassembler, I used ollydbg for a while (it isn't free though) and I kinda liked it. Good luck with modifying the ff7 :P
-
I think someone should just find a way to hook Direct3D to put an FPS lock on. I don't know if that's how FF7 works, though.
-
I think someone should just find a way to hook Direct3D to put an FPS lock on. I don't know if that's how FF7 works, though.
I tried asking people about this on hardware forums(guru3d) about a year ago. I always get the same 'enable vsync' answer.
dziugo - yea dT affects every movement unit in the game, by the way dT is allread used everywhere else in the game except the mini bike game. also i tried to explain what happens if you pause after each frame read back over the two examples. pauseing after every frame could only work if the pause amount time was calculated based upon how long it took to process the frame. it would probley be easier to do as you wouldn't need to modify any variables already there. you would run into problems on slow computers tho.
-
Yeah... I've read that and (hopefully) I understood it (correctly).
(...)pauseing after every frame could only work if the pause amount time was calculated based upon how long it took to process the frame(...)
That's EXACTLY what i meant :).
You would calculate, how long it's taken to process a frame, and then pause for an amount of time, that "is missing". If we want a 30FPS, we need every frame process-time to be fixes at about 50ms. If some frame was processed faster (ex. 26ms) we would just pause for "missing" amount of time (about 20ms).
And on slower machines, this would cause losing max 1 FPS, since the operations we need aren't very exhaustive to CPU. The problem is putting it into the ff7.exe (We need at least 1 free variable and some space).
I'll look into it when the "gypt-project" is completed...
-
That's EXACTLY what i meant :).
sorry, i missunderstood what you wrote.