È sicuro usare Sleep () nel loop di gioco (su Windows)?


27

È sicuro usare la funzione Sleep () su Windows nel game loop (C ++)? Voglio avere un frame rate fisso.


Devi chiarire cosa intendi con "sicuro". Naturalmente è sicuro e non danneggerà la memoria né farà esplodere il PC dei giocatori.
Kromster dice che supporta Monica il

Risposte:


32

No non lo è. Il sonno garantisce solo un tempo minimo per dormire, ma può effettivamente dormire per qualsiasi periodo di tempo arbitrario durante quello. La risoluzione del timer (impostata tramite timeBeginPeriod) è anche importante per questo, e anche se stai usando qualcos'altro (come QueryPerformanceCounter) per il tuo timer, hai ancora bisogno di timeBeginPeriod per controllare la sospensione.

Quindi in sintesi:

  • Il tempo per dormire è solo un minimo garantito e il tempo di sonno effettivo potrebbe essere più elevato.
  • Sensibile al valore impostato (o non impostato) tramite timeBeginPeriod.

L'unico caso ragionevole per l'utilizzo di Sleep sarebbe se si desidera ridurre l'utilizzo della CPU, ad esempio per i dispositivi mobili. Anche allora useresti Sleep (1); usarlo per controllare i framerate non è la strada da percorrere.

Forzare vsync è probabilmente un modo comune per ottenere un framerate fisso, ma anche in questo caso hardware diverso verrà eseguito a frequenze di aggiornamento diverse e non sarà possibile avere un framerate fisso coerente su macchine diverse (questo dipende dal tipo di hardware stai prendendo di mira ovviamente).

A questo punto è necessario menzionare questo articolo: Gaffer On Games - Fix Your Timestep! . Descrive i passaggi necessari per ottenere un timestep coerente nella simulazione.


Enormi grazie per il link. Fino ad ora, di solito ho usato l'approccio "timestep variabile" descritto nell'articolo.
Ivan Vučica,

La sospensione è inoltre pericolosa su macchine con Intel speed-step abilitato.
Waterwizard11,

"ma può effettivamente dormire per qualsiasi periodo di tempo arbitrario durante quello." Bene, questo deve essere provato immagino ... Non ho mai visto alcuna prova di ciò, quindi immagino che sia una di quelle "definizioni". Buona risposta però e sì, non puoi (anche se era, per così dire, accurato) usare qualsiasi tipo di sospensione per impostare un framerate fisso (bene puoi ma hai bisogno di un timer di alta precisione per farlo).
Valmond,

2
Per MSDN - "Notare che non è possibile eseguire immediatamente un thread pronto. Di conseguenza, è possibile che il thread non venga eseguito fino a qualche tempo dopo l'intervallo di sospensione". È vero, non l'ho mai visto accadere, ma allo stesso tempo, se è documentato come possibile, sicuramente non farei affidamento sul fatto che non accada mai.
Maximus Minimus,

1
Vale la pena ricordare che penso che ciò riguarderebbe "... se si volesse ridurre l'utilizzo della CPU ...": nanobit.net/doxy/quake3/win__main_8c-source.html <- il codice pertinente inizia a 01224
user_123abc

16

Risposta breve: no, non lo è.

Per avere un frame rate fisso devi chiamare una certa funzione di callback che forza un frame rate specifico. Ovviamente, se non si impiega ora una singola iterazione in un ciclo, non è possibile impostare un tempo di sospensione fisso.

GLUT fornisce glutTimerFunc () , che è, se stai programmando in OpenGL, la giusta funzione di cui hai bisogno. Dai un'occhiata a questo esempio o a questo .


1
"Dopo almeno msec millisecondi, OpenGLUT chiamerà callback" - in cosa differisce Sleep?
Kromster dice che supporta Monica il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.