Odd FPS counter

[Dave2001]

Hi!

I have a question to ask:

I'm having trouble with the fps counter in Glide64. Since Glide64 must be run in fullscreen, the pj64 fps counter is not an option to look at. On my fps counter, I get 30 fps when Mario is running full speed, and 20 fps when Zelda is running full speed. This is obviously not correct since Zelda is NOT running at 20 fps... This is when I'm updating the frame count every time the buffer is swapped.

The FPS counter seems to show 60 / number of UpdateScreen()s per ProcessDList(). When I place the frame counter at the beginning of UpdateScreen() instead of where the buffer is swapped, I get values that seem correct; 60 consistently. But this SHOULDN'T be correct, it is adding 2+ frames to the counter per buffer swap!

Here's the FPS code, but I'm pretty sure it's correct.



if (fullscreen)
{
LOG ("BUFFER SWAPPED\n");
grBufferSwap (0);

#ifdef FPS
// Check frames per second
fps_count ++;
if (fps_count >= 30)
{
LARGE_INTEGER difference;
QueryPerformanceCounter (&fps_next);

difference.QuadPart = fps_next.QuadPart - fps_last.QuadPart;
fps = 30.0f / (float)((double)difference.QuadPart / (double)perf_freq.QuadPart);
fps_last = fps_next;
fps_count = 0;
}
#endif
}

this means that on every 30th frame, calculate the FPS.

Any clue to why this might happen?

Btw, these are the functions that are being called:

Mario (30 fps):
ProcessDList ()
UpdateScreen () <- BUFFER SWAPPED HERE
UpdateScreen ()
... repeated & repeated

Zelda (20 fps):
ProcessDList ()
UpdateScreen () <- BUFFER SWAPPED HERE
UpdateScreen ()
UpdateScreen ()
...

Zelda (part that runs at 60 fps):
ProcessDList ()
UpdateScreen () <- BUFFER SWAPPED HERE
...

Obviously it somehow is depending on the number of UpdateScreens, but WHY? ???

[LD.]

I think it's because Mario actually DOES run at around 30 frames per second. The PJ64 fps counter measures something different as far as I recall. At least, that's what I read in another thread somewhere on this forum.

You seem to be getting the 'true' fps when you put the code at a buffer swap, and PJ64's fps when you put the code at every UpdateScreen.

I think you need to find someone who can see both the PJ64 fps counter and the Glide64 fps counter at the same time (having a Voodoo2 and two monitors for example) so you can check what's happening as you debug. It might also be a good idea to test it on games / machines that don't run at a constant 60fps so you can check how exact it is


[EDIT: I'm trying so hard not to make it sound like I'm begging here, but if you can't find anyone else better I'd be happy to help. Damnit, I feel like such a dirty n00b now...]

[Doomulation]

Dave,
using the beta-tester eVoodoo version, you can actually see the pj-fps bar flashing in full screen. This has been confirmed by mcleod that it is for debugging purposes.

Perhaps you could use it to investigate your problem.

[Dave2001]

While using eVoodoo, i can see both fps counters...

The problem is... using the "real" fps, when the buffers are swapped, mine gets 7 when pj64 gets 20

when I use the every UpdateScreen method, they are almost exactly the same.

[Azimer]

PJ64 counts the virtual FPS (when the N64 console is refreshing on the TV). A buffer swap doesn't always occur here. A dlist is Vsync dependant and will not run when an update is in mid-scan. Zelda renders fewer frames then Mario. That is the bottom line. The renderer is designed to drop frames when the game is going faster then output. Not an issue on a console, but as far as I have seen, all games seem to have their own "maximum" dlists/sec setting.

[Dave2001]

I actually figured this out before your post, Azimer. Thanks much though!

All of the sudden, when in a huge conversation, everything hit me at once!

The NTSC TV updates at 60hz. UpdateScreen() is actually a VERTICAL INTERRUPT! That is why it is called twice per ProcessDList() for mario. Mario is really only running at 30 frames per second, and the TV is updating at 60 hz. This makes my previous counter a VI/s counter and not a frames per second counter.

This also explains why when I used UpdateScreen(), i got the percentage of speed * 60.



thx everybody, I'll include options for both FPS counter and VI/s counter since one is the real FPS and one is a consistent comparison of speed.

[Doomulation]

Glad you finally figured it out, Dave.
Good work.

[Dave2001]

Lots of new toys to play with

[linker]

Finally

[DuDe]

Neat