All'interno del Digital Foundry: come misuriamo il frame-rate su console - articolo
Ecco svelati i nostri strumenti di analisi.
Una delle domande che ci vengono rivolte più di frequente, specialmente sul nostro canale YouTube, è: come misuriamo il frame-rate su console e creiamo i nostri video relativi alle prestazioni? C'è, su console, un equivalente di FRAPS? È una lunga storia, di cui ci siamo occupati in parte nel passato, ma uno degli aspetti che più ho apprezzato dell'ampliamento della nostra produzione video è stata l'opportunità di usarli per sfatare molti miti su ciò che facciamo e mostrare i nostri strumenti e metodologie di lavoro. Ed è proprio da qui che cominciamo.
Gli strumenti si sono evoluti immensamente da quando abbiamo cominciato ad analizzare le prestazioni su console nel 2008, ma il principio di base è rimasto immutato. Utilizziamo una scheda d'acquisizione di fascia alta per ottenere filmati non compressi dalle porte HDMI della fonte, e confrontiamo ogni singolo fotogramma con quello precedente alla ricerca di dati duplicati e linee di tearing, calcolando poi il frame-rate.
All'inizio avevamo solo uno strumento da linea di comando, FPSdetect.exe, in grado di scansionare un video acquisito e comunicarci quanto un singolo fotogramma era diverso dal precedente, in pratica tutti i dati di cui si ha bisogno per analizzare i giochi con sincronia verticale attiva. A questo si è poi aggiunto FPSgraph.exe, un altro strumento da linea di comando che utilizza i file.txt generati da FPSDetect per creare file TIFF trasparenti con i familiari grafici. È un TIFF per file, sovrapposto al video sorgente con Adobe After Effects: il procedimento era molto complicato e le opzioni di anteprima del video finale erano limitate. Ogni errore nei calcoli richiedeva l'editing manuale del file .txt e una ripetizione di tutta l'operazione. Avevamo bisogno di snellire la procedura, quindi abbiamo fatto un passo in avanti con lo strumento mostrato nel video in basso: FPSGui.
Questo tool è composto da due elementi: l'editor iniziale ci permette di definire l'aspetto del filmato in termini di grafici, font e numero di video (con opzioni per schermo unico o split-screen fino a quattro fonti). Quindi c'è il visualizzatore, contenente i dati dell'analisi per ogni acquisizione importata e varie modalità di visualizzazione. Effettuare un'analisi precisa presenta molte sfide: una di esse è il trovare i punti in cui si verifica il tearing, e queste modalità di visualizzazione sono molto utili nell'assicurare la precisione del tutto.
In teoria, per calcolare la posizione delle linee di tearing è sufficiente confrontare le linee di ciascun fotogramma con quelle del precedente, cercando blocchi di dati comuni. Nella pratica, le cose sono rese più complicate da una serie di variabili aggiuntive: a volte i dati HDMI sono 'dithered', e questo rende matematicamente diversi i fotogrammi duplicati. I giochi che girano a 60fps con sincronia adattiva possono poi vedere la comparsa di linee di tearing anche quando non vi sono dati in comune tra due fotogrammi consecutivi, rendendo difficile un approccio programmatico alla loro individuazione (Titanfall ci ha insegnato molto da questo punto di vista). In rari casi un nuovo gioco si rivela diverso da qualsiasi cosa vista prima, richiedendo correzioni manuali o modifiche nei parametri di importazione. Ed è qui che le modalità di visualizzazione di heat-map e differenza assoluta aiutano immensamente, permettendoci di vedere le acquisizioni in tonalità 'bianco e nero', simile a quella con cui opera l'algoritmo.
Il controllo di potenziali errori è facilitato molto dal grafico del frame-time, che visualizza il tempo di permanenza di ogni immagine su schermo. Il frame-time è estremamente importante perché rappresenta l'esperienza in un dato momento, segnalando gli scatti durante il gameplay. Risulta essenziale per verificare una buona distribuzione dei fotogrammi, ma anche per assicurare che l'analisi sia precisa, visto che evidenzia delle potenziali anomalie. Frame-time di 16ms in un gioco a 30fps, o scatti da 50ms in uno a 60fps sono strani, e vanno controllati. La maggior parte dei titoli vengono scansionati da FPSGui ed esportati nuovamente senza problemi, ma nel corso degli anni abbiamo capito che, nonostante i nostri algoritmi siano molto buoni, delle variabili esterne possono a volte causare problemi su un numero ridotto di titoli, ed è qui che va fatto ricorso alle modalità di visualizzazione per capire cosa stia succedendo. In sintesi, serve la verifica umana per garantire che i risultati dell'algoritmo siano corretti.
La più recente revisione di rilievo dei nostri strmenti ha visto l'aggiunta del supporto per FCAT di NVIDIA, uno strumento in sovrimpressione per PC che marca ogni singolo fotogramma con un contorno colorato in maniera diversa, rendendo molto facile il rilevamento delle linee di tearing. Questo ci permette anche di presentare i benchmark sotto forma di video, fornendo molte più informazioni sulle prestazioni PC e sui colli di bottiglia. Abbiamo anche lavorato per poter analizzare fonti compresse, come ad esempio i b-roll dei publisher. Lo strumento ha beneficiato di uno sviluppo cumulativo che ormai dura da qualche anno: nel corso del tempo sono state aggiunte diverse funzioni, ma molte (come la ripulitura del tearing) non sono più necessarie, mentre alcuni ritocchi specifici per alcuni titoli sono stati estesi ai nostri algoritmi principali.
Abbiamo tutte le funzioni di cui abbiamo bisogno, ma con l'accumularsi di nuove funzioni l'interfaccia è diventata un po' confusa, e operazioni più veloci di importazione ed esportazione del materiale sono sempre le benvenute. Inoltre, stiamo ora acquisendo video a 4K e 60fps, cosa che porta i requisiti di memoria a tutto un altro livello. Tenendo presenti queste esigenze, FPSgui è in fase di rivisitazione come applicazione a 64-bit, con tutte le aggiunte e migliorie fatte dal 2008 a oggi incluse in uno strumento più veloce, snello ed efficiente, progettato con uno sguardo al futuro. Tenendo le dita incrociate, dovrebbe bastarci per altri sette anni…