Delta Time with WASM

[Quazzy]

I'm going crazy on trying to figure out how to calculate delta time using WASM, without the use of a local time headers. As you can see down below, FBW derives it from PRE_DRAW but I'm having a hard time converting to C++. Anyone have techniques that they can show to help me out? Thanks!

aircraft/src/systems/systems_wasm/src/lib.rs at 41c0ae58d650410bcd438f7b020dec641c86be44 · flybywiresim/aircraft

The A32NX & A380X Project are community driven open source projects to create free Airbus aircraft in Microsoft Flight Simulator that are as close to reality as possible. - flybywiresim/aircraft

github.com

 

[Itay Dor]

Hello,

You can do it like this:

#include <MSFS/MSFS.h>
#include <MSFS/Legacy/gauges.h>

extern "C"
{
    MSFS_CALLBACK bool Sample_gauge_callback(FsContext ctx, int service_id, void* pData)
    {   
        switch (service_id)
        {
        case PANEL_SERVICE_PRE_DRAW:
        {
            auto pDrawData = (sGaugeDrawData*)pData;

            double deltaTime = pDrawData->dt;
        }break;
        }
        return true;
    }   
}

Itay

 

[B21-soaring]

what do you want the delta time for? There's a big difference between knowing the real time between updates and needing to calculate a derivative value from simvars.

 

[Quazzy]

what do you want the delta time for? There's a big difference between knowing the real time between updates and needing to calculate a derivative value from simvars.

Messing around with PID controllers.

 

[B21-soaring]

This comment is based on the 'deltaTime' provided to HTML/JS gauges, I'm not programming in WASM but at a guess the deltaTime will be similar (a simple test is to request the time from the sim as well as pDrawData->dt , subtract successive sim time values from each other, and see if the pDrawData->dt bear any relation to that):

I'm still not sure what calculation you're feeding the deltaTime into. If you want to calculate something across an update cycle, e.g. sink rate from (Altitude2-Altitude1)/deltaTime, then the sim 'delta time' is generally useless for that calculation (although there are multiple implementations of 'delta time' and many reasons you might want it, so you need to understand the issue rather than having a pat works/doesn't work answer).

The underlying tech challenge is in MSFS the client code accessing sim data has been moved to separate threads which are updated asynchronously. Great for stability/reliability of the core sim, but it means sim time vs. real time has become more complex (the SimVars are updated in sim time, the deltaTime values provided by MSFS are generally real time, which you could calculate easily yourself)

In the example I gave, what you would really want is two pairs [Altitude1, Time1] and [Altitude2, Time2] where Altitude1 occurred at sim time Time1, and similar for the second pair, and obviously the deltaTime you want is Time2-Time1. In practice the MSFS sim deltaTime values are 'real' time values (the sim is using the PC internal clock to calculate the real time since the last update occurred, e.g. 67.1234567 milliseconds) which is accurate in real time but not particularly useful in 'sim' time where the 'sim' time values between Altitude2 and Altitude1 might be 55.55 milliseconds or 111.11 milliseconds (sim variable updates occur on an APPROX 18-times-per-second update thread independent of the thread used to communicate with your code).

Is the issue clear? Doesn't give you a good answer (I don't know your requirement - it depends on what you want to do). Frankly very few people have any clue about this issue because there are already pre-canned variables that fit the common use cases e.g. Speed and Acceleration vars are available which internally correctly use matching distance/altitude/speed/time values so you don't need a deltaTime value for those.

If you need deltaTime in 'real' time, that can be calculated (obviously) by subtracting real timestamps inside your code (the MSFS implementation for gauges subtracts JS Date.now() values from each other, independent of whatever the sim time is doing).

If you need accurate deltaTime in 'sim time', it is wayyyyyyy more complicated, e.g. if you request [ABSOLUTE TIME, INDICATED ALTITUDE] on successive updates, and subtract the first time from the second, this generally will NOT be the sim time the plane took to fly between the two altitude samples. If you want a deltaTime spanning multiple seconds (fine for a climb averager) then subtracting two ABSOLUTE TIME values would be fine (as would any internal timestamp).