La migliore risposta è: dipende .
Non devi limitare nessuno dei due
Aggiornamenti : se gli aggiornamenti non sono vincolati a un limite superiore, la logica di gioco dovrebbe dipendere da un tempo delta , per evitare di eseguire il gioco più velocemente o più lentamente a seconda della macchina in cui viene eseguito. Questo è un approccio molto comune utilizzato da molti giochi, ma non è l'unico.
Rendering : se il rendering non è vincolato a un limite superiore, il framebuffer potrebbe essere presentato in uno stato incompleto o errato, causando artefatti laceranti . Questo è il motivo per cui molti giochi utilizzano la sincronizzazione verticale (v-sync)
Potresti limitare entrambi
Aggiornamenti : alcuni giochi utilizzano timestep fissi per alcuni o tutti i suoi sistemi di gioco. Questo approccio funziona esattamente come hai descritto. Il numero di aggiornamenti al secondo è limitato a un limite superiore per garantire che le cose non si muovano troppo velocemente su una macchina di prim'ordine. Questo elimina la necessità di delta timing. Alcune applicazioni sono migliori con timestep fissi, altre con delta timing. Scegliere quale approccio dipenderà interamente da ciò che esattamente stai cercando di raggiungere. Il libro online GameProgrammingPatterns ha un capitolo dedicato ai circuiti di gioco che tocca entrambe le architetture.
Rendering : i frame al secondo dovrebbero essere impostati su un limite superiore per evitare il problema di lacerazione sopra menzionato, tuttavia, l'applicazione non dovrebbe tentare di farlo manualmente con un blocco della CPU. Abilita invece v-sync e consenti all'hardware sottostante di sincronizzarsi con la frequenza di aggiornamento del monitor. In questo modo, il tuo gioco sarà compatibile con i futuri monitor che potrebbero operare su una frequenza molto più elevata rispetto ai 60Hz attualmente in uso. Vale anche la pena notare che molti giocatori, in particolare quelli nel benchmarking, preferiscono ancora correre senza v-sync per consentire il frame rate più alto possibile. Quindi è sensato consentire l'abilitazione o la disabilitazione della funzione durante il runtime.
Cosa non dovresti limitare
Se il tuo gioco utilizza un approccio basato sul polling per l'input dell'utente, ad esempio: chiama una getInput()sorta di aggiornamento degli stati del controller durante la fase di aggiornamento, questo è meglio se non limitato. O se limitato, impostare un limite superiore molto alto. Più spesso interroghi l'input dell'utente e agisci su di esso, più reattivo e fluido il gioco "sentirà". I cosiddetti giochi a 60Hz di cui sentiamo parlare oggigiorno non aggiornano l'intelligenza artificiale e tutti gli stati del mondo a quel ritmo, alcuni non lo rendono nemmeno così veloce, ma interrogano l'input del controller almeno 60 volte al secondo e aggiornano di conseguenza l'avatar del giocatore. Ammesso che questo sia davvero rilevante solo per i giochi d'azione frenetici.