Quali sono i vantaggi dei capping frame al secondo? (Se presente)

Sto lavorando a un semplice gioco in OpenGL, usando SDL per l'inizializzazione e l'input del display, e appare in termini di tempistica che ho due opzioni disponibili per me. Il numero uno sta dormendo solo per ottimaleTimePerFrame - theTimeTakenToRender, quando ottimaleTimePerFrame in secondi = 1 / theFramerateCap. (Non sono del tutto sicuro se ciò sia necessario, poiché equivale all'utilizzo di vsync, che potrebbe essere più accurato. Se la mia ipotesi è corretta, per favore dimmi se SDL + OpenGL ha vsync per impostazione predefinita, e se no come per abilitarlo.) L'altro è misurare il tempo trascorso dal rendering dell'ultimo fotogramma e semplicemente regolare di conseguenza il movimento. (Il tempo più breve impiegato per il rendering di un frame, le entità meno lontane si muovono in quel frame). In termini di prestazioni, riduzione dello sfarfallio ecc., Quali sono i vantaggi e gli svantaggi di questi due metodi?

Se il tempo di frame è imprevedibile (indipendentemente dal fatto che sia colpa tua; il sistema operativo potrebbe utilizzare risorse occasionalmente, ecc.), Il limite a un frame rate prevedibile che è leggermente inferiore al frame rate ottenibile farà molto per la latenza prevedibile , che può rendere il gioco molto meglio.

Cambiare il tempo che intercorre tra l'elaborazione dell'input e il rendering delle modifiche correlate a quell'input può essere negativo - anche se in media si sta ottenendo una minore latenza tra i due, il "jitter" può essere evidente agli umani (consciamente o inconsciamente).

Vedi la presentazione di Microsoft GameFest Cosa c'è in un frame: strappo, latenza e frame rate per alcune informazioni qui. Carmack ha anche una serie di post sul blog che sono utili in questo.

Inoltre, tieni presente che alcuni calcoli matematici possono essere interrotti quando esegui frame utilizzando deltaTvalori bassi o anche quando usi la variabile deltaT(le cose possono diventare più difficili o persino intrattabili da fare in modo "stabile" e prevedibile, il che è importante per le cose come replay e alcune forme di sincronizzazione della rete). Vedi Fix Your Timestep per alcuni approfondimenti qui.

Finirai per usare molta meno CPU (i multi tasker ti ringrazieranno) e anche le persone sui dispositivi mobili apprezzeranno questo.

Non dovresti mai, mai, mai, mai, usare Sleep per controllare il framerate .

Questo è stato esaminato in precedenza e ti rimanderò all'altra domanda per discutere dei motivi. Una cosa non menzionata è che alla tipica frequenza di aggiornamento moderna di 60Hz, e con la tipica granularità di 1 millisecondo di chiamate Sleep, è effettivamente impossibile dormire per la corretta quantità di tempo tra i frame.

Sto Non dicendo che cedendo CPU se hai niente da fare è una cosa negativa; lontano da esso. Ma non è la stessa cosa del controllo del framerate e Sleep è una soluzione appropriata per la prima ma non per la seconda.

Invece controlla il tempo trascorso e se è il momento di eseguire un frame, quindi fallo, altrimenti - e se vuoi produrre un po 'di CPU - Sleep per il minimo tempo - 1 millisecondo. Assicurati anche che il timer di spegnimento sia impostato in modo appropriato per la tua piattaforma in modo da darti una buona risoluzione; vale a dire che quando si emette la chiamata "Sleep (1)" si ha effettivamente la possibilità di dormire davvero per 1 millisecondo, piuttosto che qualcosa come 15, 20 o 30 (che altrimenti sarebbe il caso). Credo che SDL lo farà automaticamente per te.

Puoi anche creare un po 'di gioco, in modo che se si avvicina il tempo di eseguire un frame, smetti di dormire e inizi a correre fino a quando il frame non viene eseguito, il che può aiutarti a raggiungere l'intervallo di frame desiderato in modo più accurato.

Ciò che finisce per sembrare è un sacco di chiamate Sleep (1) intervallate dal frame occasionale, e va bene. Stai ancora abbandonando la CPU quando non ti serve, ma i tuoi frame saranno comunque in grado di funzionare in tempo.

Probabilmente il vantaggio più importante del frame rate massimo è che può aiutare a prevenire danni fisici alla macchina. Si sono dimenticati di farlo su Starcraft II, che si è rivelato molto problematico (e costoso) per alcuni utenti fino a quando non lo hanno corretto.

Come accennato in precedenza, riduce l'utilizzo della CPU. D'altra parte, e sempre più importante, che riduce anche la durata della batteria. Ad esempio, FTL funziona con quasi il 100% di CPU sul mio MBA. Di conseguenza, scarica la batteria in> 2 ore e funziona molto caldo. (Come risultato più diretto, ho disinstallato e non lo gioco più ...). Un tappo del telaio avrebbe impedito questo.

Un altro vantaggio non menzionato è che, se si tratta di un gioco multiplayer, livelli anche il campo di gioco dando a tutti la stessa esperienza.