Right now my code as the follwing method of timing: read time1 drawGame(); read time2 figure out fps from time2-time1 the problem is that between when it read time2 and then time1 again alot of windows specific stuff happened. Stuff that: #1 takes time #2 varies alot as windows does its crazy microsoft things. So I changed my timing to do the following drawGame read time2 figure out fps from time2-time1 read time1 Obviously on the first pass the calculation is wrong since time1 has a random value, but each subsequent frame calculates all the windows stuff + the time it took to render the frame. Isnt this more accurate ? Which method is more correct ? Nitzan ------------------------- www.geocities.com/nitzanw www.scorchedearth3d.net -------------------------

How about:

read new time
figure out fps: new time - stored time
stored time = new time
drawGame();

"Don''t be afraid to dream, for out of such fragile things come miracles."

erf, as they say on gameAI.com :
"You know your game is in trouble when you wonder if you could optimize your fps counter function in order to gain extra fps"

I like that saying. Its funny.

Actually with the change above (#2) my fps drops down by alot, since I am no longer just counting the OpenGL part of the code, but the window/microsoft part of the code as well.

Thanks for your help.

Nitzan

-------------------------
www.geocities.com/nitzanw
www.scorchedearth3d.net
-------------------------

what i actually do is set up a timer thingy so that i get a windows timer message approximately every 1 second (i say approximately because windows wouldn''t accurately know if 1 second had elapsed to save itself), the i use my performance timer (class) to evaluate how much time has really passed.

All the while, my render loop has been incrementing a counter every time it completes a frame. Thus, working out the FPS is a simple matter of num_frames / actual_time_elapsed (actual time elapsed in seconds is returned as a double precision floating pt num). After taking this measurement the counter is obviously set back to zero.

I find that this approach averages out a lot of the fluctuation in the frame rate, and gives a much smoother measure of FPS (as you are really working it out per second, rather than per poofteenth of a second )

oh dear... i have had too much to drink tonite, and i need sleep... can''t believe i''m p[osting on gamedev

*slumps over desk*