Motor bike race

[The SaiNt]

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.

 

[-gone away-]

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

 

[Veclord]

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.

 

[-gone away-]

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.

 

[dziugo]

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...

dziugo

 

[Veclord]

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?

 

[dziugo]

(...)the frame limiter in GTA3(...)

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...

 

[-gone away-]

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   .

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.

 

[dziugo]

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

 

[sfx1999]

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.

 

[-gone away-]

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.

 

[dziugo]

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...

 

[-gone away-]

That's EXACTLY what i meant .

sorry, i missunderstood what you wrote.