Fisso vs.frame rate variabili nei giochi:cosa è meglio e quando?

Question

Dopo aver lavorato per un po' allo sviluppo di giochi, sono stato esposto sia a frame rate variabili (dove calcoli quanto tempo è trascorso dall'ultimo tick e aggiorni di conseguenza il movimento dell'attore) che a frame rate fissi (dove calcoli quanto tempo è trascorso dall'ultimo tick e aggiorni il movimento dell'attore di conseguenza) è trascorso e scegli di selezionare un periodo di tempo fisso o di dormire fino all'arrivo della finestra successiva).

Quale metodo funziona meglio per situazioni specifiche?Si prega di prendere in considerazione:

• Soddisfare le diverse specifiche del sistema;
• Facilità di sviluppo/manutenzione;
• Facilità di trasferimento;
• Spettacolo finale.

Answer 1

Sembra che la maggior parte degli sviluppatori 3D preferisca FPS variabili:i motori Quake, Doom e Unreal aumentano e diminuiscono in base alle prestazioni del sistema.

• Per lo meno devi compensare i frame rate troppo veloci (a differenza dei giochi degli anni '80 che giravano negli anni '90, decisamente troppo veloci)
• Il tuo ciclo principale dovrebbe comunque essere parametrizzato in base al timestep e, purché non sia troppo lungo, un integratore decente come RK4 dovrebbe gestire la fisica senza problemi. Alcuni tipi di animazione (sprite con fotogrammi chiave) potrebbero essere difficili da parametrizzare.Anche il codice di rete dovrà essere intelligente, per evitare che i giocatori con macchine più veloci sparino troppi proiettili, ad esempio, ma questo tipo di limitazione dovrà essere fatto comunque per la compensazione della latenza (la parametrizzazione dell'animazione aiuterebbe anche a nascondere il ritardo della rete)
• Il codice di temporizzazione dovrà essere modificato per ciascuna piattaforma, ma si tratta di una piccola modifica localizzata (sebbene alcuni sistemi rendano difficile un timing estremamente preciso, Windows, Mac, Linux sembrano ok)
• I frame rate variabili consentono le massime prestazioni.I frame rate fissi consentono prestazioni costanti ma non raggiungeranno mai il massimo su tutti i sistemi (sembra essere un punto fermo per qualsiasi gioco serio)

Se stai scrivendo un gioco 3D in rete in cui le prestazioni contano, dovrei dire di stringere i denti e implementare frame rate variabili.

Se si tratta di un puzzle game 2D probabilmente puoi farla franca con un frame rate fisso, magari leggermente parametrizzato per computer super lenti e modelli dei prossimi anni.

Answer 2

Io propendo per un modello con framerate variabile, ma internamente alcuni sistemi hanno un timestep fisso.Questo è abbastanza semplice da fare utilizzando un accumulatore di tempo.La fisica è un sistema che è meglio eseguire con un passo temporale fisso e, se necessario, spuntare più volte per fotogramma per evitare una perdita di stabilità e mantenere la simulazione fluida.

Un po' di codice per dimostrare l'uso di un accumulatore:

const float STEP = 60.f / 1000.f;
float accumulator = 0.f;

void Update(float delta)
{
    accumulator += delta;

    while(accumulator > STEP)
    {
        Simulate(STEP);
        accumulator -= STEP;
    }
}

Questo non è affatto perfetto ma presenta l'idea di base: ci sono molti modi per migliorare questo modello.Ovviamente ci sono problemi da risolvere quando il framerate di input è oscenamente lento.Tuttavia, il grande vantaggio è che non importa quanto veloce o lento sia il delta, la simulazione si muove a una velocità costante nel "tempo del giocatore" - che è dove eventuali problemi verranno percepiti dall'utente.

Generalmente non mi occupo del lato grafico e audio, ma non penso che siano influenzati tanto quanto la fisica, l'input e il codice di rete.

Answer 3

Un'opzione che, come utente, vorrei vedere più spesso è la modifica dinamica del livello di dettaglio (in senso lato, non solo in senso tecnico) quando i framerate variano al di fuori di un intervallo certiano.Se stai eseguendo il rendering a 5FPS, disattiva la mappatura dei rilievi.Se stai eseguendo il rendering a 90FPS, aumenta un po' gli extra e offri all'utente alcune immagini più belle con cui sprecare CPU e GPU.

Se fatto bene, l'utente dovrebbe ottenere la migliore esperienza dal gioco senza dover accedere alla schermata delle impostazioni e modificare se stesso, e dovresti preoccuparti meno, come progettista di livelli, di mantenere lo stesso numero di poligoni nelle diverse scene .

Naturalmente, lo dico come utente di giochi, e non come utente serio: non ho mai tentato di scrivere un gioco non banale.

Answer 4

Il problema principale che ho riscontrato con i frame time a lunghezza variabile è la precisione in virgola mobile e i frame time variabili possono sorprenderti nel modo in cui ti mordono.

Se, ad esempio, stai aggiungendo il tempo del fotogramma * la velocità a una posizione e il tempo del fotogramma diventa molto piccolo e la posizione è grande, i tuoi oggetti possono rallentare o smettere di muoversi perché tutto il tuo delta è andato perso a causa della precisione.Puoi compensare questo problema utilizzando un accumulatore di errori separato, ma è una seccatura.

Avere tempi di frame fissi (o almeno un limite inferiore alla lunghezza del frame) consente di controllare la quantità di errore FP di cui tenere conto.

Answer 5

La mia esperienza è abbastanza limitata a giochi piuttosto semplici (sviluppati con SDL e C++), ma ho scoperto che è abbastanza semplice implementare un frame rate statico.Lavori con giochi 2D o 3D?Presumo che ambienti 3D più complessi trarrebbero maggiori benefici da un frame rate variabile e che la difficoltà sarebbe maggiore.