How do you guys get the frame rate (in FPS)?The method I'm trying is failing in FSX.

I use Shift-Z. You can not accurately measure framerate from within a gauge.

Ok... so I'm going to have to roll my own.I'll just use a high-resolution timer, and compute it each frame.

Except it still won't be accurate.Measuring inside a gauge will only tell you the # of times that gauge's render process is called per second. It is not assured to be 100% accurate representation.

>Except it still won't be accurate.>>Measuring inside a gauge will only tell you the # of times>that gauge's render process is called per second. It is not>assured to be 100% accurate representation.I can time each game-loop down to the nanosecond level, and the inverse of that time is the frame's 'instantaneous' frame rate. So, it is plenty accurate for me.

So... why do you post a thread asking how... if you want to argue that your way is already best?

>So... why do you post a thread asking how... if you want to>argue that your way is already best?Who's arguing my way is best? Not sure where you get that Ed.I asked the question, both to see how others do it in comparison, and perhaps learn something, and to share what I have discovered with my code.What you posted is that "it can't be done". I have done that a few times too, only to find out someone else has done it. We all have a lot of knowledge and experience, and share it. Sometimes in the sharing, I discover I'm wrong.I have to laugh that sometimes I can do the most complex things, yet the simple stuff gets me.Personally, I enjoy the exchange of ideas and opinions as we all learn more. This is science, don't take it so personal. If you still think it can't be done, well you are entitled to your opinion.I love this chinese saying, "Man who says it cannot be done, should not stand in way of anyone doing it". :DPatrick

What I posted is that you can not get accurate frame rates from within the gauge itself, emphasis on accurate.I won't delve into the details of why, that's a whole different topic of discussion.

Accuracy varies by CPU, but

You're mistaking time accuracy with accuracy of what you're actually measuring.I know for a fact it's possible for FS to provide higher frame rates in 3D (out the window) versus frame rates for a panel, as well as vice versa.I know you want to stick to your guns, but I can assure you I can write code that either slows the panel down or slows the 3D world down... not both, but either or. You'd be quite surprised at the frame rates shown... honestly.

>You're mistaking time accuracy with accuracy of what you're>actually measuring.Really? I know precisely what I'm measuring, I think it is you who are confusing what you believe me to be measuring and what I am measuring. Perhaps because you have attached different meanings to terms I am using. I'm just measuring how long it takes to "loop" back to the same place in my code, which I am calling a "frame", as is standard in the gaming industry.>I know for a fact it's possible for FS to provide higher frame>rates in 3D (out the window) versus frame rates for a panel,>as well as vice versa.If you are suggesting that FS's terrain engine may be running at a different frame rate from the panel system, it really has nothing to do with the frame rate I am attempting to measure. My frame rate just tells me how much my physics engine must move stuff based on the time. And really, what the terrain display engine does is not my concern.Very interesting that you discovered they have different loops.>I know you want to stick to your guns, but I can assure you I>can write code that either slows the panel down or slows the>3D world down... not both, but either or. You'd be quite>surprised at the frame rates shown... honestly.Why on earth would you want to slow them down? Haha. Anyway, I really don't care that FS has separate rendering loops, as I couldn't care less what the display frame rate is in either render loop since that is not what I'm attempting to measure as you have assumed.This is purely a physics calculation for my panel, and that is all, and it is precisely what I needed to measure to make it loop.You were probably attempting something way more complicated than what I'm doing.

This: "How do you guys get the frame rate (in FPS)?" does not match what you now state you were seeking. Though, based on your last paragraph it's apparent you think it did. :(

>This: "How do you guys get the frame rate (in FPS)?" does not>match what you now state you were seeking. Though, based on>your last paragraph it's apparent you think it did. :(Yes, my statement assumes we are talking about the frame rate of the panel system (what I'm working with), and I was not aware that FS might use more than one game loop. I should have been clearer in my purpose and what I was trying to do to avoid confusion.Anyway, no harm no foul.Interestingly, I have discovered more. Using this code:FLOAT64 CALLBACK C_GAUGE(Needle_Cb_)(PELEMENT_NEEDLE pelement){ mSecsCurrFrame = GetTickCount(); if( mSecsCurrFrame > mSecsPrevFrame ) { frameTime = mSecsCurrFrame - mSecsPrevFrame; mSecsPrevFrame = mSecsCurrFrame; } return Tot::Temp(); // A call to the TOT object for temp}That apparently the previous code did not work as the frequency it was called exceeded the resolution of the timer. This code works at it basically doesn't calculate the frameTime until there is a difference.Even more interesting is that this corresponds with the displayed FPS (ctrl-Z) ( 1/frameTime = FPS ) in my tests.Anyway, given that this callback should not be called any more frequently than 55ms (and on my 12 fps system even less) I am surprised that I cannot detect a change in GetTickCount() each time through the callback.This code is, of course, simpler to use than the high-res timer.I think for my purposes, rather than mess with this at all what I'm going to do is use my 20ms timer to just do the sound (which requires this level of feeding), and set up one other timer at perhaps 5 Hz for polling the keyboard, joystick, and updating a simple counter that I can then use to adjust physics values.So, each update, the TOT object can determine, for example, how much to adjust the temperature (up/down) based on how many "ticks" have occured in my timer counter. This then means I can define the 'rates' for such things in terms of value / second and have it be frame rate independent, which is my goal.This is a very basic requirement with any game, to be frame rate independent given user computers can vary.

Actually, the needle's callback will be done as often as FS's main loop can call it.The only part of a gauge that is assured to be 55ms between calls is in the main gauge callback... the PRE_UPDATE service ID.The use of GetTickCount is an issue.... I hope you're aware that it's value does roll-over. One might say it's unlikely, but as example, my system is never shut down... thus that function's value indeed hits a roll-over point.The OS (not FS), offers a rather simple and easy to use set of functions for measuring elapsed time. You might want to do some research as it will provide accuracy without any overhead or risk at all.

Interesting point about the needle callback. I will have to measure that and confirm that it could be called faster than a 18hz.While you are correct that the ULONG will roll over, the roll over is "handled" by the above code in a way that will have no noticable (or what we called "clinically significant" way in my phd program) impact on the update of my calculations.The purpose of this thread was to provide you an oportunity to share what each of us has learned, rather than merely critique code. I love the saying I saw recently as a footer on someone's post: "Those that can code, those that can't critique". :DIf you wish to share your technique (which is probably better) we all await.I'm just thinking out loud and sharing what I'm doing.