Frame rate limiting in FF7

[dziugo]

Hello,

This is another boring (really boring, seriously ) tech-related-topic by dziugo. If you aren't interested in this kind of stuff, stop reading now, no need to waste your time here .

For those who haven't yet closed their InternetExplorer window...

Prologue - Info about rdtsc

What is rdtsc? It's an instruction of modern (286+ i think... ) CPUs that fills the EAX and EDX registers (yep you're right, 64-bit value) with the amount of clock cycles since the start of system. This value is kept by the CPU and is increased every [1/CPU speed] second. I have an Athlon XP 2000+ on-board, so this value is increased every 0.000000000602 seconds in my CPU. Why am I talking about that? You'll see (or you won't? anyone got to this part? ).

Part1 - FF7 benchmarking your CPU

When FF7 is launched it (kind of) benchamrks your CPU. It checks how many clock cycles are done in 1000ms (it's 1663653990 on my computer). Basically it's just a speed of your CPU in Hertz. After that, this value is stored (address: 0x014F2B80) and used whenever it's necessary.

Part2 - FF7 using simple frame limiter

As we all know (well, I didn't, but you've probably knew ), FF7 uses a frame limiter to make it run at similar speed on different computers. How it's done? Let's take a SubmarineMiniGame

When initialising the MiniGame, the value found under 0x014F2B80 is divided by 30.0 (meaning - FPS-limit is 30.0). FF7 also subtract 10000.0 from the result (it's some kind of speeding-it-up, but why it's done?). FF7 calls rdtsc before every frame, and stores that value. Then it does all the dirty job (scene creating). When it's done, it calls rdtsc one more time and calculates the difference between the new value and old value. After that, it pauses if necessary (well.. it's just a loop which is ended when the actual value is greater than the one it calculated at initialising the MiniGame). Simple isn't it? It keeps the frame rate under the 30.0FPS (about...). But... what happens, when the CPU isn't fast enough to keep processing the frames? Theoretically, it won't do any frame-skipping, since it's coded to run at 30.0FPS.

Part3 - Other frame limits in FF7

Here are the FPS limits for each FF7-internal system (could contain errors):

Battle - 15.0FPS
Field - 30.0FPS (subtracts 10000.0 from the result)
Menu - 60.0FPS
Submarine - 30.0FPS (subtracts 10000.0 from the result)

Part4 - Misc stuff and ending

First, the misc stuff:
 - timeGetTime is called in SubmarineMiniGame to calculate the FPS rate for debugging, nothing more (AFAIK)
 - I don't know, how much the FF7 speed is affected by using the multi-threading OS (well, at least it looks good...)
 - In HighwayMiniGame, the rdtsc-calculating are done, but not used

I'll try to implement the frame-limiting in the HighwayMiniGame, but i don't know how long will it take (if ever). Also, I'm looking forward to check what Smithie has done already with his dT. For those, who've read the whole topic - congrats . Yep it's the end.

dziugo

[ficedula]

I doubt it's of any use, but as a bit of interesting history to add to the analysis; when FF7 came out Cyrix processors were still around, and one of the problems FF7 had originally was that it wouldn't run on them. Partly because the FPU sucked (although that was a speed issue), but mostly because RDTSC wasn't supported on the CPU.

They did fairly quickly release a Cyrix patch which, I believe, patched the RDTSC instruction to call timeGetTime instead. It certainly wasn't a new EXE and it claimed to be patching the existing one in place.

I know this because I had one of the Cyrix chips at the time and I had to borrow a friends' internet connection to download the patch - back in the dark days of 1998 I didn't even have dialup of my own

(So yes, it's not 286+ at all - I think it was introduced with the Pentium, so the programmers probably assumed only 486's wouldn't support it. Since you needed 133MHz+ to run FF7, that wouldn't be a problem? Well, except for Cyrix chips which did run at 133MHz but didn't support all the new Pentium instructions...

[dziugo]

That's interesting. I was wondering, why the Cyrix patch had to be released (hey it's just a CPU, right? ). Thanks for that explanation.

dziugo

[Kinseek]

Battle - 15.0FPS

Isn`t that kinda low and semi-choppy? Would increasing it to say, 60FPS produce any nice benefits or doesn`t it matter?

[dziugo]

Battle - 15.0FPS

Isn`t that kinda low and semi-choppy? Would increasing it to say, 60FPS produce any nice benefits or doesn`t it matter?

Did you even noticed that it runs at 15.0FPS? Basically, increasing the frame rate will also result in increasing the battle speed... (easy to count, faster 4 times if your computer is good enough to process 60 frames per second)

[Kinseek]

Battle - 15.0FPS

Isn`t that kinda low and semi-choppy? Would increasing it to say, 60FPS produce any nice benefits or doesn`t it matter?

Did you even noticed that it runs at 15.0FPS? Basically, increasing the frame rate will also result in increasing the battle speed... (easy to count, faster 4 times if your computer is good enough to process 60 frames per second)

Err, nope .

And that`s what I thought would happen..

[Sir Canealot]

The frame rate limited in battle is either different or broken or something. Battles may be called to run at 15fps, but do they actually run at 15fps on anyone's computers? I remember the battles would run at like 100+fps on one of my older, around 1.5ghz or more, machines. And the battles don't run faster either.

Or am I just picking up the wrong end of the stick? :/

[dziugo]

It's always 15.0FPS... unless you somehow disabled frame-cap.

[James Pond]

yeah, 15 fps battle, 23 fps (I think) in game.


It hurts my eyes'es ;_;

[Decayrate]

to watch 100fps is sweet but 15 its sadens my eyes

[Cyberman]

to watch 100fps is sweet but 15 its sadens my eyes

You mean it makes you cry?
Well 15 FPS is the fixed rate for battle animations.  All of the battle animations are fixed as well.  The only way to improve it without the animations looking like they are going at warped speed is linear or cubic interpolation between frame.  This however should be limited to a multiple of the screen refresh rate.  This also is likely to only be doable with software that runs the FF7 Data files, and not the original game.

Welcome to the forums

Cyb

[Sir Canealot]

The battles don't run at 15fps. Compare a Psx/Ps2 running FFVII to a PC runnning the game. The PSX version is hella more jerky (actually 15fps), while the PC version is hella slow.

[dziugo]

The battles don't run at 15fps. Compare a Psx/Ps2 running FFVII to a PC runnning the game. The PSX version is hella more jerky (actually 15fps), while the PC version is hella slow.

So, what is the frame-rate for PC version?

[-gone away-]

why dont you just include an option to set the fps limit when it installs so we can set our own. for the mini games i mean not the entire game.

i personally would like the bike game a bit faster than what you have set it too.

[dziugo]

why dont you just include an option to set the fps limit when it installs so we can set our own. for the mini games i mean not the entire game.

i personally would like the bike game a bit faster than what you have set it too.

Ok, but for now it will still be a command-line tool, so configuration may be difficult.

[-gone away-]

it only needs to be simple when you run the installer just ask for a fps limit with a cout & cin.

Can you run your installer over a version where it has allready been installed or will it screw it up

[dziugo]

Updated.

Now it's possible to set a frame-cap for both supported minigames.

Link here.

I'll leave the "ask for a fps limit" for multipatcher writers since it's only a command-line tool ('coz my design always... hmm... looks bad).

dziugo