Pubblicato un nuovo aggiornamento per retroArch, il frontend Libretro introduce una nuova opzione conosciuta come “Automatic Frame Delay” all’interno del sottomenu Latenza (che si trova in Impostazioni -> Latenza).

Questa nuova funzionalità fornisce un modo efficace per evitare di dover configurare un valore specifico per l’opzione “Frame Delay” per ogni core e singolo contenuto che potresti voler eseguire, riducendo automaticamente la sua forza in base alle prestazioni del tuo sistema.

RetroArch 1.9.13 released! #Libretro #RetroArchhttps://t.co/uEzVm1JIP8

Download – https://t.co/PNm0dQaiMr
Support us (Github Sponsors): https://t.co/HSNg1sXMXb
Support us (Patreon): https://t.co/7iAGs0L2PN#RetroArch #Libretro

— libretro (@libretro) November 7, 2021

L’impostazione nota come “Frame Delay” esiste da tempo in RetroArch. Tuttavia, per la sua natura e la complessità del suo effetto, ha sempre richiesto un livello di regolazione e messa a punto strettamente manuale da parte dell’utente.

Il modo in cui i fotogrammi vengono renderizzati e quindi visualizzati sul video può essere compreso meglio considerando questa sequenza:

• Ogni frame ha una durata prefissata, ovvero un “frame time” o “frame period” come viene comunemente chiamato, che su uno schermo a 60hz e in circostanze ideali corrisponde ad una lunghezza media di 16,7 millisecondi;
• Come da immagine sopra riportata, una volta mostrato il primo fotogramma inizia la preparazione del fotogramma successivo “dietro le quinte”. Questo processo di rendering include il momento in cui gli input vengono interrogati e tutto avviene entro il periodo di frame assegnato;
• In situazioni tipiche il processo di rendering del frame successivo è terminato un po’ di tempo prima della fine del periodo di frame specificato;
• Ciò si traduce nel successivo frame sostanzialmente in “stallo”, essendo lasciato in uno stato sospeso per alcuni millisecondi in più del necessario, fino a quando il periodo di frame non è correttamente terminato;
• Solo a quel punto viene presentato a schermo il frame appena creato.

Mentre il processo descritto avviene normalmente, di solito non produce un impatto considerevole sulla latenza, il fatto che il frame successivo debba essere messo “in attesa” e attendere un certo periodo di tempo dal momento in cui termina il rendering fino alla fine del frame period infatti contribuisce alla reattività combinata degli input.

Qui entra in gioco il “Frame Delay”.

A seconda del valore impostato per l’opzione “Frame Delay”, la creazione del nuovo frame comprensivo di input polling può essere posticipata di un certo numero di millisecondi, fino all’ultimo momento realisticamente praticabile.

Ciò richiede una maggiore potenza di elaborazione della CPU a seconda della quantità di ritardo scelta, ma aiuta anche a ridurre il numero di millisecondi che il nuovo frame, che è stato preparato ed è pronto per essere presentato su video, deve rimanere in attesa.

Di conseguenza, la regolazione dell’impostazione “Frame Delay” può offrire un leggero, sebbene misurabile, miglioramento della latenza di input percepita.

L’impostazione “Automatic Frame Delay”

Il problema con l’impostazione “Frame Delay” è che i molti core e tipi di contenuti disponibili, come ci si potrebbe aspettare, sono molto diversi e spesso hanno vari gradi di requisiti di sistema e CPU.

Gli utenti hanno dovuto modificare costantemente i valori di “Frame Delay” per ogni situazione specifica, spesso ricorrendo all’impostazione di override per core o per contenuto, in modo che i benefici della riduzione della latenza potessero essere ottenuti senza inciampare in cali di framerate, stutter, scoppiettio audio e tutti i tipi di altri problemi.

Con l’introduzione dell’opzione “Automatic Frame Delay”, l’utilizzo di questa funzionalità diventa più semplice: la quantità di tempo di ritardo per il rendering del nuovo frame si ridurrà automaticamente, se il sistema rileva qualsiasi fluttuazione/caduta del framerate, fino a raggiungere un valore che consente al tuo gameplay di rimanere stabile pur mantenendo un certo grado di riduzione della latenza.

Di seguito una rapida carrellata dei diversi modi in cui è possibile abilitare e applicare questa impostazione, in base alle proprie preferenze:

• Se si imposta “Frame Delay” su 0 e “Automatic Frame Delay” su ON, il punto di partenza del ritardo che viene applicato al nuovo frame sarà metà del “periodo di frame”. Ad esempio, su un tipico schermo a 60hz con un frame time di 16,7 ms, il valore iniziale applicato sarà “8”, come in 8 millisecondi di ritardo. Successivamente, se vengono rilevati cali o singhiozzi nelle prestazioni video, questo valore verrà ridotto dinamicamente fino a raggiungere un punto stabile;
• Se si imposta “Frame Delay” su qualsiasi valore maggiore di 0 e “Automatic Frame Delay” su ON, il punto di partenza sarà il valore di ritardo impostato manualmente. Ad esempio, se “Frame Delay” è impostato su 10, il ritardo iniziale per l’elaborazione del nuovo frame sarà di 10 ms. Quindi, verrà regolato verso il basso nel caso in cui venga rilevato un calo del framerate;
• Se si imposta “Frame Delay” su qualsiasi valore maggiore di 0 e “Automatic Frame Delay” su OFF, la scalatura automatica dell’impostazione del frame delay sarà disabilitata. La quantità di ritardo applicata al rendering del nuovo frame sarà esattamente quella scelta e non cambierà o diminuirà affatto durante il gioco;
• Se si imposta “Frame Delay” su 0 e “Automatic Frame Delay” su OFF, non verrà applicato alcun ritardo al rendering del nuovo frame. Frame Delay sarà completamente disabilitato.

Conclusione

Sebbene gli effetti tangibili del “Frame Delay” sulla latenza totale combinata potrebbero essere piccoli rispetto ad altre implementazioni come Runahead, questa impostazione ha il vantaggio di essere applicabile a tutti i core e i contenuti, anche se in misura diversa.

L’ulteriore comodità di avere il “Frame Delay” ridimensionato automaticamente è un’altra risorsa per garantire che tu possa eseguire i tuoi contenuti con la latenza più bassa possibile.

Changelog

• CHEEVOS/MSVC2010: Aggiunto il supporto per Cheevos.
• CRT/SWITCHRES: Corretti alcuni problemi per cui il ridimensionamento non risultava corretto in alcune modalità video per l’output CRT.
• FRAMEDELAY: Aggiunta l’opzione ‘Automatic Frame Delay’.
• INPUT: Aggiunta l’impostazione “Menu di controllo di tutti gli utenti”: qualsiasi gamepad può controllare il menu quando è abilitato. L’unica limitazione in questo momento è che solo il giocatore 1 può attivare il menu, ma qualsiasi combinazione di controller di commutazione menu impostata funzionerà bene per tutti gli utenti, quindi per ora dovrebbe essere accettabile.
• INPUT/UDEV: Correzione della barra Dolphin e protezione contro l’aggiunta di dispositivi senza il rilevamento di mouse o pulsanti a sfioramento.
• NETPLAY/CLI: Correzione della riga di comando -C/--connect.
• NETPLAY: Altri miglioramenti.
• NETPLAY: Rimossa la disconnessione forzata su comando netplay sconosciuto – sarà retrocompatibile con qualsiasi versione che abbia rimosso questa disconnessione. invece di disconnetterci, leggiamo semplicemente i dati e ignoriamo, come fanno la maggior parte delle implementazioni di rete
• TASKS/CHEEVOS: Sostituite le coroutine con task/thread.
• TASKS/DATABASE/EXPLORE: Inizializza il menu “Esplora” su un thread in background – niente più stallo quando si passa con il mouse sulla scheda Esplora.

Download: RetroArch v1.9.13

Download: Source code RetroArch v1.9.13

Link: Collegamento Patreon

Fonte: github.com