ELAPSED_SECONDS

[Guest Patrick_Waugh]

Maybe it is late... but I thought I could do this: MODULE_VAR elapsed_seconds = { ELAPSED_SECONDS }; double prevSecs; double currentSecs; lookup_var(&elapsed_seconds); prevSecs = elapsed_seconds.var_old.n; currentSecs = elapsed_seconds.var_value.n; elapsed_seconds.var_old.n = currentSecs;in FS9, but now it does not seem to work for me in FSX.What am I missing as later when I do this:FLOAT64 FSAPI C_GAUGE(GetFps_)(FLOAT64 number, ID id, PCSTRINGZ string, MODULE_VAR *source_var, PGAUGEHDR gauge){ double frameTime = currentSecs - prevSecs; return frameTime; //return 1.0 / frameTime; // FPS}I get zero(0) returned.

[ddawson 35]

I've always done it this way:lookup_var(&elapsed_seconds);prevSecs = currentSecs;currentSecs = elapsed_seconds.var_value.n;if ( currentSecs > prevSecs ) frameTime = currentSecs - prevSecs;else frameTime = 0.; //Defends against ELAPSED_SECONDS resetting.Doug

[Guest Patrick_Waugh]

Thanks Doug, I'll try this. I see the difference now.I'm trying to avoid going to a high resolution timer.

[Guest Patrick_Waugh]

Ok,I tried this: FLOAT64 currentSecs; FLOAT64 prevSecs; FLOAT64 secondsPerFrame; case PANEL_SERVICE_PRE_UPDATE: lookup_var(&elapsed_seconds); prevSecs = currentSecs; currentSecs = elapsed_seconds.var_value.n; if ( currentSecs > prevSecs ) secondsPerFrame = currentSecs - prevSecs; else secondsPerFrame = 333; // For testing only break;And unfortunately, secondsPerFrame remains at 333 (ie currentSecs is NEVER > prevSecs). I set up a dynamic tooltip to show me the value.Interestingly, if I use the tooltip to look at the currentSecs var, it does increment.The code seems right, yet prevSecs remains the same as currentSecs. In fact, if I do a tooltip and show both, and press pause, they are identical. Weird.

[ddawson 35]

I think pressing Pause is your problem. This variable does not increment when the sim is paused.Doug

[Guest Patrick_Waugh]

No Doug, they are equal before I press pause... all pause does is allow me to "freeze" it so I can view it too.With the above 333 test code, it shows 333 (meaning they are equal) even if I do not pause.This is the strangest thing.

[WarpD 824]

There is nothing in the SDK documetation that states we can assign to such variables as "elapsed_seconds.var_old.n;" Yes, I know... many have used it in the past.However, since the documentation doesn't tell you it's available for your use... well... ;)I'd strongly suggest using a local variable instead.

[Guest Patrick_Waugh]

>There is nothing in the SDK documetation that states we can>assign to such variables as "elapsed_seconds.var_old.n;" Yes,>I know... many have used it in the past.>>However, since the documentation doesn't tell you it's>available for your use... well... ;)>>I'd strongly suggest using a local variable instead.Ed, yes, that is how "we" changed the code, so now it only tries to use a local.I have a feeling this may be an order issue. Perhaps I have to move the tooltip code to the PRE_DRAW, so that it is sure to be done with the PRE_UPDATE.Of course, the tooltip is just a debugging tool. I really am just trying to get an FPS, and actually the inverse 1/FPS so that I can calculate the amount to 'move' valuse in a frame rate independent way.

[Guest Patrick_Waugh]

>I've always done it this way:>>lookup_var(&elapsed_seconds);>prevSecs = currentSecs;>currentSecs = elapsed_seconds.var_value.n;>if ( currentSecs > prevSecs ) frameTime = currentSecs ->prevSecs;>else frameTime = 0.; //Defends against ELAPSED_SECONDS>resetting.>>Doug>Interestingly when I do this: FLOAT64 currentSecs = 0; FLOAT64 prevSecs = 0; FLOAT64 secondsPerFrame = 0; ... case PANEL_SERVICE_PRE_UPDATE: prevSecs = currentSecs; // Store time of last frame lookup_var(&elapsed_seconds); currentSecs = elapsed_seconds.var_value.n; if ( currentSecs > prevSecs ) secondsPerFrame = currentSecs - prevSecs; else secondsPerFrame = 0; //Defends against resetting if( currentSecs == prevSecs ) prevSecs = 0; // TEST CODE ONLY break;Indeed, prevSecs is always equal to currentSecs (and gets set to zero).So, I am at witts end trying to understand how this is true, given that currentSecs (and prevSecs with it normally) does indeed increment.

[WarpD 824]

The order of code is your issue:case PANEL_SERVICE_PRE_UPDATE:lookup_var(&elapsed_seconds);currentSecs = elapsed_seconds.var_value.n;if ( currentSecs > prevSecs ) secondsPerFrame = currentSecs - prevSecs;elsesecondsPerFrame = 0; //Defends against resettingprevSecs = currentSecs; // Store time of last framebreak;

[WarpD 824]

You're welcome.

[Guest Patrick_Waugh]

>You're welcome.Ed,Thanks for trying, but that is not the problem. Regardless of if you store the value from the last frame (at the top) or store the current value at the bottom for the next frame, you get the same result.Anyway, given your experience I tried your version in case I was needing to learn something here, but as I said the results are the same.I think the problem must lie outside this code. But it is ok, as I am abandoning this simple approach in favor of the high-resolution timer as I can no longer get it to work as it had in FS9.It just bugs me (guess that's why they call them bugs) that I cannot figure out why these vars are staying equal when there is no other code using them. I am displaying them from another gauge, but this should still be fine.

[WarpD 824]

Based on what little code you've posted, there is no legitimate reason for the value to remain at 0.I'll have to state that there's something that isn't being revealed by your posts.