proper time measurement

[Guest ghrasko]

I need proper time measurement for various advanced navigation system components. For sake of simplicity let's say I need a good enough clock gauge that could measure time properly in FS. I am not interested in the synchronisation of FS time and system time. My FS clock should show the time that was used by FS for the simulation. I have a simulated equipment that is based on a Doppler radar. It measures speed in a gyro-based X-Y coordinate system and I read the raw values from FORWARD_GROUND_VELOCITY and SIDE_GROUND_VELOCITY. Based on these data the system is keeping track of aircraft position within the X-Y coordinate system. To simulate this correctly I need known time intervals as s = v * t. I know v and I would like to calculate s. I retrieve velocity vectors at every "working tick", but I am not sure what time interval I should calculate with. Is it 1/18 second for sure?My users reported - and I also experienced - that on a 100km trip my equipment measures some 96km only, so it is slower than expected. There could be two explanations for this:1/ I am calculating s as v * t where t = 1/18sec. It seems that t > 1/18sec as with the given v the s is larger by some 4% that what i calculate. How would I know the exact value of t? By exact t value I mean the time FS is using to simulate the movement. It is not necessarily the time the CPU is using running FS. An obvious difference is when you use time acceleration.2/ The s = v * t equation is not strictly correct in the simulation. In this case there is not much to do.One recommended to use high resolution timers, but I think it is not correct, as that is a PC timer and is not taking it into consideration how much time is spent in the FS world, i.e. used within the simulation equations.An additional challenge is to properly detect pause and time acceleration. Pause could mean a user pause or a pause caused by other reasons. As I see my gauge functions and even the main CHAIN_18HZ_SYNC timer routines might be called in some pause situations, so I can not rely on them totally.All-in-all the core question is how to make a good-enough resolution clock implementation in FS?Gabor

[Guest Patrick_Waugh]

>One recommended to use high resolution timers, but I think it>is not correct, as that is a PC timer and is not taking it>into consideration how much time is spent in the FS world,>i.e. used within the simulation equations.You will get inaccurate results using TICK18. Why not try ELAPSED_SECONDS, which although inaccurate too is self-correcting for your purposes.>An additional challenge is to properly detect pause and time>acceleration. Pause could mean a user pause or a pause caused>by other reasons. As I see my gauge functions and even the>main CHAIN_18HZ_SYNC timer routines might be called in some>pause situations, so I can not rely on them totally.Each frame (tick) in PRE_UPDATE save the previous ELAPSED_SECONDS at the end of the function, and at the beginning compare the current frame value to the last frams value to get the time of the frame. If the current and previous values are the same, then you are "paused". switch (service_id) { case PANEL_SERVICE_PRE_DRAW: lookup_var(&elapsed_seconds); isPaused = elapsed_seconds.var_value.n - elapsed_seconds.var_old.n == 0; elapsed_seconds.var_old.n = elapsed_seconds.var_value.n; break;Another way would be to register an FS Event handler, and get notified when the user invokes the PAUSE event. You would get a callback on any pause.If you use ELAPSED_SECONDS, then time acceleration will be automatically handled.>All-in-all the core question is how to make a good-enough>resolution clock implementation in FS?Failing the above, then like in most games, you'll have to run your own WMI timer, but it is not that hard to do really, however as the timer is not in-sync with game-time I think the above will be more accurate for simulating an inertial reference system and such.Good luck

[Guest ghrasko]

Thanks, this is something I was looking for. You are right, this solution should be "self-correcting" in longer runs, which is enough for me.I never used the var_old member of the structure. I believed it is updated internally, but as I knew nothing about it, I did not touch. Is elapsed_seconds a static or global variable in your example? Gabor

[Guest Patrick_Waugh]

>Is elapsed_seconds a static or global variable>in your example?You are mixing apples and oranges with this question."Global" means external to any function, while "static" refers to linkage. A variable can be both "global" and "static" (internal linkage) or "global" and "external" (external linkage, the default).To answer your question, elapsed_seconds is a MODULE_VAR (a structure) declared and defined like this: MODULE_VAR elapsed_seconds = { ELAPSED_SECONDS };for external linkage (meaning you can get it with extern in other files if it is external to any function, or like this: static MODULE_VAR elapsed_seconds = { ELAPSED_SECONDS };if you want it with internal linkage, and only available locally.The choice is yours, and will depend on where you use it. As I handle the pause checking locally within my gauge callback function, it need not be global. Your mileage may differ.Patrick

[Guest ghrasko]

Not apples and oranges :) I was meaning global or local_and_static, i.e. of course not simple local in the function. Thanks.

[Guest Patrick_Waugh]

Yes, it is apples and oranges.One is "scope" and the other "linkage". They are very different things and you must know the difference clearly.To confuse them will cause you many difficulties.