È normale che un gioco utilizzi una CPU al 100%?

Ho appena implementato la gestione dell'input multi-thread nel mio motore di gioco in cui il codice che esegue il polling del sistema operativo per raccogliere input da esso e time stamp li è in un thread separato e ogni frame nel thread principale ho appena mangiato l'input raccolto fino a un tempo di gioco logico. Funziona tutto, ma questa configurazione utilizza il 100% della mia CPU. Ho due core e sta salendo al 100% mentre eseguo il mio gioco.

Ho controllato con altri giochi per vedere se anche loro lo fanno. Ad esempio Skyrim e Doom 3 sembrano andare bene con poco più del 60% di CPU.

È accettabile per un gioco che utilizza input multi-thread per utilizzare fino al 100% di CPU? In caso contrario, quali sono alcuni trucchi che tali giochi usano per ridurre l'utilizzo della CPU da parte del thread di input?

Sì, è normale che un gioco in tempo reale cerchi di utilizzare la CPU al 100% per ottenere le prestazioni più veloci e buone possibile. Quindi quel giocatore vede tanti frame al secondo o una buona simulazione fisica o qualsiasi altra cosa che il suo PC possa fornire.

Nel tuo caso - No, sembra un design inefficiente, prendere un thread e farlo sondare per gli eventi in un ciclo ( while true do CheckForEvents;). Correggimi se sbaglio, ma il sistema operativo esegue già il polling degli eventi. Dovresti semplicemente controllarli dal tuo thread principale una volta ogni tick.

Il ciclo di gioco principale dovrebbe essere abbastanza veloce da funzionare con oltre 30 tick al secondo, il che è abbastanza per comandi di polling per molti giochi. Il giocatore non vedrà alcuna differenza se i suoi comandi vengono elaborati, ad es. 0-33 ms più tardi. D'altra parte, avresti potuto usare quel core aggiuntivo della CPU per attività più vantaggiose, come AI molto meglio o fisica o altro.

PS Come richiesto per chiarire nei commenti, non prendere sopra i numeri alla cieca per tutti i tipi di giochi. Mentre il gioco TBS potrebbe richiedere solo 1 tick per turno e il gioco RTS potrebbe andare bene con 10 tick al turno, altri generi, come RaceSims hanno bisogno di molto di più. E ovviamente non legare tick di logica con framerate, queste sono due cose separate.

Un gioco con un costante aggiornamento della finestra attiva verrà eseguito principalmente in modalità a schermo intero e sarà l'unico (grande) programma della macchina gestita dal sistema operativo. Quindi è assolutamente accettabile utilizzare il 100% della CPU, perché nient'altro dovrebbe averne bisogno.

Tuttavia , ciò non significa ovviamente che devi sempre usare il 100% qualunque sia il tuo stato di gioco. La maggior parte dei loop di gioco usano un metodo sleep come delimitatore di framerate se hanno finito di eseguire il rendering di un frame prima del limite di frame rate, al fine di non utilizzare la CPU per nulla.
Questo è probabilmente ciò che accade nei tuoi esempi: la tua macchina è più veloce di quanto Skyrim o Doom 3 debbano funzionare, quindi usano solo ciò di cui hanno bisogno, ma tutto ciò di cui hanno bisogno.

Come diceva @KromSterm, il sistema operativo di solito esegue già il polling degli eventi, quindi non è necessario eseguire un ciclo più velocemente di quello del sistema operativo. Se hai solo due core, utilizzare il 100% del secondo solo per il rilevamento di eventi non è una buona idea, perché se trasferisci solo eventi nel ciclo di aggiornamento principale, è molto veloce da eseguire. Dovresti invece provare a utilizzare questo core per una parte del processo principale del thread con un altro thread.

Ci sono alcuni svantaggi di puntare a utilizzare tutto il tempo disponibile della CPU in un PC o in un gioco mobile.

Requisiti di sistema: se il gioco è giocabile sul PC in cui si sviluppa il gioco, potrebbe non essere giocabile su un PC più debole di proprietà di qualcuno che ha acquistato il gioco. Limitare l'uso della CPU manterrà un gioco utilizzabile su macchine che probabilmente più persone avranno già. Se vuoi davvero vedere se stai limitando il tuo mercato, testa i tuoi giochi per PC e quelli dei tuoi concorrenti su un dispositivo staccabile alimentato da Atom come il Transformer Book o prova i tuoi giochi mobili su un telefono Android prepagato economico.

Consumo energetico: un computer portatile scarica la batteria più velocemente quando vengono utilizzati quattro core al 100 percento della frequenza massima rispetto a quando, diciamo, due core vengono utilizzati al 60 percento della metà frequenza. Quindi assicurati che il thread di polling del controller, il thread AI, il thread fisico e il thread grafico siano bloccati fino a quando non è il momento di eseguirli nuovamente. Tranne che in alcuni generi molto nervosi, come il combattimento e il ritmo, non sarà necessario eseguire il polling dei controller più velocemente di circa 60 Hz, quindi impostare il thread di polling su un timer a 60 Hz.

Variabilità fisica: se la fisica che influenza il gameplay è più dettagliata su macchine più potenti, la stessa azione del giocatore avrà risultati diversi su macchine diverse. Ciò significa che il giocatore può essere in grado di imbrogliare usando una macchina più forte o più debole. Id's Quake III Arena è noto per avere frame rate che influisce sull'altezza del salto . Per evitare ciò, molti giochi usano un passo temporale fisso per la fisica. Ma ciò non influisce sulla fisica che è disconnessa dal gameplay, come effetti particellari o effetti stoffa o interpolazione di coordinate tra fotogrammi fisici per rendere il video con una frequenza fotogrammi più alta rispetto alla fisica. Quindi progetta la tua fisica usando alcune varianti del controller di vista modello architettura, in cui le cose essenziali (accelerazione, rilevazione dei colpi e simili) vanno nel modello e la vista accattivante va nella vista.

Variabilità dell'IA: se l'IA è più dettagliata su macchine più potenti, i nemici si comporteranno in modo diverso su macchine diverse. Ad esempio, in un'implementazione Go o Chess, l'avversario sarà più debole su un PC più debole e i giocatori possono imbrogliare giocando su un PC più debole o eseguendo processi in background come la transcodifica antivirus o video o gli aggiornamenti del sistema operativo.