// just to let you know wich type the variables are:
double g_dElapsedTime;
float g_fFrameRate;
float g_fFrameTime;
LARGE_INTEGER g_startTime;
LARGE_INTEGER g_EndTime;
LARGE_INTEGER g_Frequency;
// Begin the scene
QueryPerformanceCounter(&g_i64StartTime);
// End the scene
QueryPerformanceCounter(&g_i64EndTime);
QueryPerformanceFrequency(&g_i64Frequency);
g_dTimeScale = 1.0 / g_i64Frequency.LowPart;
g_dElapsedTime = (g_i64EndTime.LowPart - g_i64StartTime.LowPart) * g_dTimeScale;
g_fFrameRate = 1.0f / (float)g_dElapsedTime;
g_fFrameTime = (float)g_dElapsedTime;
QueryPerformanceCounter & Frametimes
Author
There is something funny about my game.
i used fraps to benchmark the average FPS of the game, plus the frametimes.
my game sais that it runs with about 80 fps, thats just the same as fraps claims. but the frame time differs. one frame takes for about 12 ms, fraps sais it is done in about 6ms.
why does this happen? it should be nearly the same value, but the frametimes are somehow doubled.
i thought it would work.
since the frequency is 1 / s, i will get the time for each "beat" by reversing the frequency...
multiplying with deltaTime should just return the frametime, but somehow it is doubled o.O
*edit*
i just calculated the frametime for 80 fps, it should be around 12,5 ms.
is the benchmark for fraps bugged? *g
A better way to get the frame time is to look at the delta between the same point in your code between frames. E.g., before you "begin the scene", grab the time and compute the difference between this and the last time you began the scene.
What you are timing is the time it takes to issue commands to the run-time, rather than the time taken to execute them. Although this would usually result in you getting artificially lower frame times (and higher fps).
Hmm... Also, what's up with the .LowParts? Just cast them to doubles, these values are 64bit for a reason. ;-)
What you are timing is the time it takes to issue commands to the run-time, rather than the time taken to execute them. Although this would usually result in you getting artificially lower frame times (and higher fps).
Hmm... Also, what's up with the .LowParts? Just cast them to doubles, these values are 64bit for a reason. ;-)
Author
i am a bit confused about using 64 bit variables.
how should i proceed with calculating the frametimes?
LARGE_INTEGER contains a low and a high part, how should i convert this structure so i am able to fill a double with its value?
i have never worked with 64 bit integers before
how should i proceed with calculating the frametimes?
LARGE_INTEGER contains a low and a high part, how should i convert this structure so i am able to fill a double with its value?
i have never worked with 64 bit integers before
LARGE_INTEGER l;
l.HighPart=1;
l.LowPart=1;
double d = (double)l.QuadPart; // Here's the conversion
This should give you a double with 2^32 + 1 in it. QuadPart is a LONGLONG, which is a typedef'ed __int64 which is a primitive type that can be cast to a double (don't you just love C++? ;-) ).
Using just the lowpart would give you all sorts of crazy timings, since this would overflow about 1 to 2 times per second.
l.HighPart=1;
l.LowPart=1;
double d = (double)l.QuadPart; // Here's the conversion
This should give you a double with 2^32 + 1 in it. QuadPart is a LONGLONG, which is a typedef'ed __int64 which is a primitive type that can be cast to a double (don't you just love C++? ;-) ).
Using just the lowpart would give you all sorts of crazy timings, since this would overflow about 1 to 2 times per second.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
