Final Fantasy VII - Remaining Issues

[DLPB_]

I have decided to make a list of problems that remain with Final Fantasy VII.  Hopefully this will kick start some action.  If you have anything to add, please post here.

1. Submarine Minigame is incomplete.  It was left in a really crappy state. It was also left with the original Japanese defaults, and not the later tweak for the International version. I am currently fixing this up and giving it some life via the Reunion.

2. Credit screen has no frame limiter.  It will run at vsync, and if this isn't on, it will run as fast as your PC will allow.  Aali added a frame limiter for the battle swirl, and this needs one too.

3. Battle is not 60fps (like PSX), meaning menu items run 4x less smooth.  I have created a quick fix for this, but the project started by Obesebear will be a more complete solution.

4. Some models have not been updated by Kaldarasha.  The vast majority have.

5. Sound effects sometimes play when the volume is set to 0. 

6. The eyes of the characters are still visible after summon fade outs...  This may have happened with PSX.

7. Field scrolling has a bug.  Every second or so, it will skip a few pixels (observe the scroll the first time you enter Wallmarket).  This is present with PSX version.  I am going to look into it.

8. Frame limiters are a joke.  Something is seriously wrong with PC version.  It seems to have been thrown together.  Frame rate seems to suffer with some (including me) when vsync is enabled. Even when it isn't, I don't think it's quite reaching 15fps, 30fps or 60fps.  It is falling short.  Dziugo was in the process of fixing this issue when he got busy a long while back.

9.  Probably related to 8.  When recording with Fraps/DXtory, or anything else, there is a frame loss of around 3fps.  It's almost as if the game is designed to do it.  It's very annoying, and the only way to stop it happening is to let fraps/dxtory do the limiting by setting ff7 to run at a higher speed.  Please note this "bug" exists regardless of OS, computer spec, or recording software.  I am not sure how it fared without Aali's driver, but I am guessing probably the same or worse.

---in progress---

[halkun]

The PSX version uses a universal hardware "Root Counter" from the GPU to keep track of the framerates. (root counters can be attached to the pixel clock, Hsync, and Vsync, so it can fire every pixel, every scanline, or every frame) This probably didn't translate well to PC as the only real thing we have is Vsync trigger. Also credits was a separate overly executable in the PSX so it probably used root counters differently then the battle modulel/field module/minigame

[DLPB_]

So basically, we need to make the current system better and also add a proper frame limiter for the credits?  Still weird that the current frame limiter they made for PC is so shoddy... 

[nfitc1]

I don't see a common frame limiter that each of the draw methods use. It's just sorta baked into the battle draw and I can't find anything that resembles a limiter for the field/world map draw methods.

Also, if vsync is on for the credits and refresh is at 60Hz, why doesn't the sequence achieve 60 fps? I don't even notice a difference when I turn my vsync off (or maybe I'm not turning it off completely).

[DLPB_]

I don't see a common frame limiter that each of the draw methods use. It's just sorta baked into the battle draw and I can't find anything that resembles a limiter for the field/world map draw methods.

Also, if vsync is on for the credits and refresh is at 60Hz, why doesn't the sequence achieve 60 fps? I don't even notice a difference when I turn my vsync off (or maybe I'm not turning it off completely).

You're turning on/off vsync in aalis driver?  And making sure it isnt forced off/on in graphic card settings?  Pretty sure my credits screen achieves 60fps with vsync on.

[nfitc1]

You're turning on/off vsync in aalis driver?  And making sure it isnt forced off/on in graphic card settings?  Pretty sure my credits screen achieves 60fps with vsync on.

The flip?! I've been approaching your credits problem as if it's limiting the frames to 30fps. No wonder I can't find a limiter, there isn't one. Turning vsync off in both Aali's driver and video settings does not change this. So you WANT to limit it to 60 fps if vsync is off, yes? I've been misunderstanding all this time.

[DLPB_]

   Yeah, with and without vsync, the fps should be 60 for the credits screen.  But from what Halkun is saying, and based on the battle swirl, a limiter needs coding in.  Beyond me. 

[DLPB_]

I'm currently looking into the skip issue with scrolling.  Seems it jumps 2 (or maybe 3) pixels instead of 1 every 47 frames.

The main function (possibly broken) that deals with scrolling is 6430A4 , called from  643F72

[nfitc1]

...But from what Halkun is saying, and based on the battle swirl, a limiter needs coding in.  Beyond me. 

Code: [Select]

FrameLimiter ( byte fps )
{
   Entrytime = timegettime
   while( true )
      if ( ( 1000 / fps ) >= ( timegettime - Entrytime ) ) break;
}
n'est-ce pas?

[DLPB_]

I understand that, but not placing it in with Assembly. 

Perhaps that's also why the limiter is falling short during normal play...  because 1000 div 60 will not give you 60fps.  (Actually shouldn't it give you slightly more, because it rounds up to 17? or is it truncated to 16?)

[Aali]

Code: [Select]

FrameLimiter ( byte fps )
{
   Entrytime = timegettime
   while( true )
      if ( ( 1000 / fps ) >= ( timegettime - Entrytime ) ) break;
}
n'est-ce pas?

This is the kind of shoddy code that gets us inconsistent framerates in FF7 in the first place. You have to take into account the time it takes to process/render the frame, you can't just wait a predetermined amount of time after each frame.

[nfitc1]

This is the kind of shoddy code that gets us inconsistent framerates in FF7 in the first place. You have to take into account the time it takes to process/render the frame, you can't just wait a predetermined amount of time after each frame.

Haha. I understand that. That's the most primitive frame limiter I could come up with because DLPB said he didn't know how.
That kind of limiter would never work because redrawing never takes the same amount of time. That's probably why battles were limited to 15 fps to begin with on the PSX.

The ideal way is to have a timer fire off the whole redraw routine every 16.66667 milliseconds. However I don't think x86 asm has access to that accurate a timer nor is this app multi-threaded enough to do that.

[DLPB_]

I use asphyre for Borland Delphi and so these days I don't need to mess about with all this stuff, it's done for me.  It's beena  while since I had to program something using time based calculations. But isn't there a way to use QueryPerformanceFrequency?  It will return the number cycles in 1 second (to microsecond accuracy).  And from that you can work out when 1 frame should be by using QueryPerformanceCounter. 

From what I remember , the game has to be constantly asking for the current count for this to work. I don't know how C or assembly deals with that. 

Would this work Aali?  And if not, how wouldf you go about fixing the current issues?

Assuming your process is updating the loop enough times, this code works:

Code: [Select]

var
i: LongInt;
Freq, LastCount, CurrentCount: Int64;

Begin
QueryPerformanceFrequency(freq);
QueryPerformanceCounter(Lastcount);
i:=0;

  while true do
  begin

  QueryPerformanceCounter(Currentcount);
 
    if CurrentCount - LastCount >= freq / 60 then
    begin
    inc(i);
    QueryPerformanceCounter(Lastcount);
    end;

  Application.processmessages; // I don't know what the C equivalent of this is. 
                                               // Apparently it is DoEvents
  end;

end;

i will increment its value 60 times a second.  [i.e., this is the frame rate.  And  your main game loop]

But as Aali said, perhaps this way is just fundamentally flawed.  It won't be on machines that are fast enough.  If not, the game will slow down.  But at least it's a proper frame limiter.

[nfitc1]

Somewhere at the beginning of the exe's execution:

Code: [Select]

QueryPerformanceFrequency( frameDelta );
frameDelta /= 60;
int64 lastTime = 0; //first frame will need no delaying
frameDelta is stored statically so we don't waste ticks calculating and calling QPF over and over.
lastTime would need to be global as we'll see next.

Somewhere in the function at 0x66059C before the call at 0x6605C2:

Code: [Select]

int64 thisTime;
QueryPerformanceCounter( thisTime );
while( thisTime - lastTime < frameDelta )
   WaitMessage;  //I think this is the correct thing to go here to prevent sound from stuttering. I'm not entirely sure though
   queryPerformanceCounter( thisTime );
lastTime = thisTime;

That would ensure that the fps would never go above 60 by stalling processing if it processes faster. This might make sound stutter or input lag.  Input lag wouldn't be noticeable as it's done per-frame, but the sound might be depending on how it's handled.

That's only marginally better than my previous suggestion.