Il movimento sembra dipendere dalla frequenza dei fotogrammi, nonostante l'uso di Time.deltaTime

Ho il seguente codice per calcolare la traduzione richiesta per spostare un oggetto di gioco in Unity, che viene chiamato LateUpdate. Da quanto ho capito, il mio uso di Time.deltaTimedovrebbe rendere indipendente la frequenza di fotogrammi della traduzione finale (si prega di notare che CollisionDetection.Move()sta solo eseguendo i raycast).

public IMovementModel Move(IMovementModel model) {    
    this.model = model;

    targetSpeed = (model.HorizontalInput + model.VerticalInput) * model.Speed;

    model.CurrentSpeed = accelerateSpeed(model.CurrentSpeed, targetSpeed,
        model.Accel);

    if (model.IsJumping) {
        model.AmountToMove = new Vector3(model.AmountToMove.x,
            model.AmountToMove.y);
    } else if (CollisionDetection.OnGround) {
        model.AmountToMove = new Vector3(model.AmountToMove.x, 0);
    }

    model.FlipAnim = flipAnimation(targetSpeed);
    // If we're ignoring gravity, then just use the vertical input.
    // if it's 0, then we'll just float.
    gravity = model.IgnoreGravity ? model.VerticalInput : 40f;

    model.AmountToMove = new Vector3(model.CurrentSpeed, model.AmountToMove.y - gravity * Time.deltaTime);

    model.FinalTransform =
        CollisionDetection.Move(model.AmountToMove * Time.deltaTime,
            model.BoxCollider.gameObject, model.IgnorePlayerLayer);
    // Prevent the entity from moving too fast on the y-axis.
    model.FinalTransform = new Vector3(model.FinalTransform.x,
        Mathf.Clamp(model.FinalTransform.y, -1.0f, 1.0f),
        model.FinalTransform.z);

    return model;
}

private float accelerateSpeed(float currSpeed, float target, float accel) {
    if (currSpeed == target) {
        return currSpeed;
    }
    // Must currSpeed be increased or decreased to get closer to target
    float dir = Mathf.Sign(target - currSpeed);
    currSpeed += accel * Time.deltaTime * dir;
    // If currSpeed has now passed Target then return Target, otherwise return currSpeed
    return (dir == Mathf.Sign(target - currSpeed)) ? currSpeed : target;
}

private void OnMovementCalculated(IMovementModel model) {
    transform.Translate(model.FinalTransform);
}

Se blocco il framerate del gioco a 60FPS, i miei oggetti si muovono come previsto. Tuttavia, se lo sblocco ( Application.targetFrameRate = -1;), alcuni oggetti si sposteranno a un ritmo molto più lento di quanto mi aspetterei quando si raggiungono ~ 200FPS su un monitor da 144Hz. Questo sembra accadere solo in una build autonoma e non all'interno dell'editor Unity.

GIF del movimento degli oggetti all'interno dell'editor, FPS sbloccato

http://gfycat.com/SmugAnnualFugu

GIF di movimento degli oggetti all'interno della build autonoma, FPS sbloccato

http://gfycat.com/OldAmpleJuliabutterfly

Le simulazioni basate su frame presenteranno errori quando gli aggiornamenti non riescono a compensare i tassi di variazione non lineari.

Ad esempio, si consideri un oggetto che inizia con valori di posizione e velocità pari a zero, con un'accelerazione costante di uno.

Se applichiamo questa logica di aggiornamento:

velocity += acceleration * elapsedTime
position += velocity * elapsedTime

Possiamo aspettarci questi risultati con frame rate diversi:

L'errore è causato trattando la velocità finale come se fosse applicata per l'intero fotogramma. Questo è simile alla somma di Riemann destra e la quantità di errore varia con la frequenza dei fotogrammi (illustrata con una funzione diversa):

Come sottolinea MichaelS , questo errore verrà dimezzato quando la durata del frame viene dimezzata e potrebbe diventare irrilevante con frame rate elevati. D'altra parte, tutti i giochi che presentano picchi di prestazioni o frame di lunga durata possono scoprire che questo produce comportamenti imprevedibili.

Fortunatamente la cinematica ci consente di calcolare accuratamente lo spostamento causato dall'accelerazione lineare:

d =  vᵢ*t + (a*t²)/2

where:
  d  = displacement
  vᵢ = initial velocity
  a  = acceleration
  t  = elapsed time

breakdown:
  vᵢ*t     = movement due to the initial velocity
  (a*t²)/2 = change in movement due to acceleration throughout the frame

Quindi, se applichiamo questa logica di aggiornamento:

position += (velocity * elapsedTime) + (acceleration * elapsedTime * elapsedTime / 2)
velocity += acceleration * elapsedTime

Avremo i seguenti risultati:

Dipende da dove stai chiamando il tuo passo. Se lo chiami da Update, il tuo movimento sarà effettivamente indipendente dal framerate se ridimensioni con Time.deltaTime, ma se lo chiami da FixedUpdate, devi ridimensionare con Time.fixedDeltaTime. Immagino che stai chiamando il tuo passaggio da FixedUpdate, ma ridimensionando con Time.deltaTime, il che comporterebbe una riduzione della velocità apparente quando il passaggio fisso di Unity è più lento del ciclo principale, che è ciò che sta accadendo nella tua build autonoma. Quando il passaggio fisso è lento, fixedDeltaTime è grande.