FPS di grandi dimensioni vs FPS coerenti

Quando ottimizzo la frequenza dei fotogrammi di un gioco, quando dovrei concentrarmi su un FPS di grandi dimensioni e quando dovrei concentrarmi su un frame rate costante.

Questo è spesso un problema fortemente contestato, quindi tieni presente che non sto chiedendo quale sia la migliore.

Quali sono i pro ed i contro di ognuno?
In quali situazioni si preferisce l'una all'altra?

Nota anche: il mio polling / elaborazione di input, la fisica e le velocità di aggiornamento del gioco sono indipendenti dalla mia frequenza dei fotogrammi. L'unica cosa che colpisce l'FPS è la frequenza di rendering di uno schermo.

Questo è soggettivo, ovviamente, ma penso che la coerenza sia molto più importante per il gioco rispetto alla velocità.

Fondamentalmente, i giocatori tollereranno un frame rate più lento se il gioco è coerente, divertente da giocare e non stonante. Tuttavia, anche se il gioco oscilla totalmente, se dà alle persone mal di testa da guardare perché esplode e / o non riescono a controllare le cose, si arrabbieranno e smetteranno di giocare.

Così...

Concentrarsi su FPS coerenti durante la progettazione e lo sviluppo.

Concentrati su FPS più veloci (ma ancora coerenti) quando il gioco è quasi finito e hai tempo per migliorare le prestazioni senza preoccuparti di correzioni di bug, ecc.

Un modo per ottenere prestazioni migliori consiste nell'utilizzare callback / delegati / interrupt (a seconda della lingua / piattaforma) anziché il polling.

Cosa dovresti fare:

• Blocca la logica di gioco su un framerate fisso
• Rendering della grafica il più velocemente possibile

In questo modo, se il framerate diminuisce non si ottiene un ritardo di input (ti sto guardando, Just Cause 2) e se il framerate diventa troppo alto (pensa ai giochi degli anni '90) il gioco non diventa ingiocabile.

Ecco come lo faccio:

s_PhysicsCurrent = GetTickCount();
float delta = (float)(s_PhysicsCurrent - s_PhysicsStart);
s_PhysicsStart = s_PhysicsCurrent;

s_PhysicsTime += delta;

while (s_PhysicsTime > ONEFRAME)
{
    // Update
    Game::Tick(ONEFRAME);

    // Clear input
    Keyboard::Clear();
    Mouse::Clear();

    s_PhysicsTime -= ONEFRAME;
}

s_Window->Clear();

Game::Render();

s_Window->Swap();

In pratica raccogli una "pila" di frame per cui fare la logica e puoi interpolarli perfettamente.

Sembra che tu abbia almeno due thread di esecuzione, con il rendering sul proprio thread. In tal caso, in realtà hai due frame rate di cui preoccuparti. Ti consigliamo di essere il più veloce possibile. Tuttavia, dipende anche dal tipo di gioco che stai costruendo.

Stai costruendo uno sparatutto in prima persona, in cui piccole cadute nella frequenza dei fotogrammi potrebbero dare un vantaggio a un avversario? In tal caso, ti consigliamo di assicurarti che il tuo fps medio sia abbastanza alto, ma ti preoccupi anche dei tempi del frame peggiore. Stai costruendo un gioco da tavolo? In tal caso, il picco temporale occasionale non ucciderà l'esperienza dell'utente.

Nei miei giochi, il mio processo è di solito qualcosa del genere:

• Esegui un profiler sul codice
• Guarda il frame rate medio. Se è troppo basso in media, aumenta i fps medi ottimizzando le cose lente.
• Una volta che i fps medi sono abbastanza alti, cerca i tempi dei fotogrammi nel caso peggiore (fotogrammi in cui vedi grandi picchi nel tempo di calcolo o di rendering). Cerca di ottimizzare gli scenari peggiori per migliorare il tempo di frame peggiore.

Se la maggior parte delle volte si è a 30 fps, ma si arriva a 200 ms ogni 10 secondi, ciò causerà problemi. Ma se hai una media di 15 fps, porta prima i tuoi fps medi.

Quindi, la risposta breve sarebbe probabilmente: ottimizzare qualunque cosa apporti prima il massimo miglioramento all'esperienza dell'utente.

Il blocco dell'FPS su un numero coerente consente di:

• Mantenere un aspetto visivo uniforme
• Mantieni le animazioni in esecuzione in un tempo lineare, gli oggetti fisici cadono a una velocità costante tra i fotogrammi, ecc.
• Tuttavia, la parte più utile del blocco del tuo FPS è che sui frame in cui hai dei tempi di inattività puoi fare altro lavoro - raccogli rifiuti, lavori in streaming nella prossima area della mappa, ecc. E avrai un po 'di margine durante il rendering qualcosa di grande e brillante o quando si abbatte una pila di scatole.

Tutti e due. Direi idealmente, costantemente oltre 60 fotogrammi al secondo. Realisticamente, costantemente oltre 30 fotogrammi al secondo. Meno di 30 fotogrammi al secondo e inizia a influire sulle prestazioni del giocatore (a proposito, sto pensando ai giochi basati su FPS / twitch, i giochi di strategia possono probabilmente andare più in basso).

Se davvero dovessi dire l'uno o l'altro, andrei con coerenza. Se riesci a garantire un frame rate, puoi concentrarti sullo spostamento di quel framerate garantito più in alto.

Più grande è sempre meglio, ma:

Framerate incoerenti possono portare a cinetosi.

(Abbiamo avuto un tester interno vomitato quando il suo framerate è saltato tra 20 e 60 per 10 secondi.)

Penserei che vorresti un FPS coerente e più grande. Più la grafica è liscia (a causa della frequenza di aggiornamento), meglio è. Se inizia a scendere al di sotto di 30 FPS, i tuoi utenti inizieranno a notare il nervosismo e saranno frustrati dalla mancanza di tempo di risposta alle azioni.

Se vuoi evitare lo strappo , dovresti usare V-sync che bloccherà l'FPS alla frequenza di aggiornamento del monitor, o inferiore (se vai in alto non sarà visibile, quindi sarebbe uno spreco).

C'è solo una risposta, e cioè ... andare sempre in alto durante lo sviluppo e quando il tuo down lo porta al picco più basso, questo porterà il gioco in un flusso costante malato. Sono seduto sul codice e rimarrà lì perché è il mio modo segreto del drago codificante. / Eyhe