Motor bike race

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