Disponibile un nuovo e interessantissimo aggiornamento per il core Libretro paraLLEl N64 dotato dell’innovativo renderer VulKan paraLLEl-RDP.

Per la prima volta in assoluto, l’accurato renderizzatore Angrylion ad alta intensità è stato trasferito dalla CPU alla GPU grazie alla potente API grafica di basso livello Vulkan.

Questo, combinato con un plugin RSP alimentato da dynarec, ha reso finalmente possibile una più corretta emulazione delle ROM N64 su configurazioni hardware modeste.

ParaLLEl RDP è il primo renderer RDP a basso livello al mondo in grado di eseguire l’upscaling. L’output grafico che si ottiene è diverso da qualsiasi renderer HLE che si sia mai visto negli ultimi vent’anni.

È possibile effettuare l’upscaling in passi interi della risoluzione di base. Quando si imposta l’upscaling della risoluzione su 2x, si sta moltiplicando la risoluzione di input per 2x. Quindi 256×224 diventerebbero 512×448, 4x sarebbero 1024×896 e 8x sarebbero 2048×1792.

A differenza di molti renderer HLE, ParaLLEl RDP emula completamente l’interfaccia VI dell’RCP. Come parte delle routine di postelaborazione di questa interfaccia, applica automaticamente un’approssimazione di 8x MSAA (Multi-Sampled Anti-Aliasing) all’immagine.

Ciò significa che anche se la nostra risoluzione interna potrebbe essere 1024×896, questo sarà ulteriormente attenuato da questo aggressivo passo post-elaborazione AA.

Ciò comporta che anche i giochi che funzionano con una risoluzione nativa solo 2x sembrano significativamente migliori della stessa risoluzione in esecuzione su un renderer HLE RDP.

Come installarlo e configurarlo

L’upscaling RDP è disponibile in questo momento su PC Windows, Linux e Android. Non garantiamo il tipo di prestazioni che ci si può aspettare da queste piattaforme, tutto dipende dai driver Vulkan della GPU e dalla sua potenza di calcolo.

Comunque, ecco come puoi ottenerlo.

• In RetroArch, andare su Online Updater.
• (Se paraLLEl N64 è già installato) – Selezionare Aggiorna core installati. Questo aggiornerà tutti i core che hai già installato.
• (Se non hai già installato paraLLEl N64), andare su Core Updater (versioni precedenti di RA) o Core Downloader (versione più recente di RA) e selezionare Nintendo – Nintendo 64 (paraLLEl N64).
• Ora provare ad eseguire un gioco con questo core.
• Andare al menu rapido e su “Opzioni”. Scorrere l’elenco verso il basso fino a raggiungere “GFX Plugin”. Impostalo su “parallel”. Impostare anche il “plugin RSP” su “parallel”.
• Per rendere effettive le modifiche, ora è necessario riavviare il core. Puoi chiudere il gioco o uscire da RetroArch e riavviare il gioco.

Per effettuare l’upscaling, devi prima impostare il fattore di upcaling. Per impostazione predefinita, è impostato su 1x (risoluzione nativa). Impostandolo su 2x/4x/8x, quindi riavviando il core si attiva l’upscaling.

Spiegazione delle opzioni principali

Sono state aggiunte alcune funzionalità nuove di zecca all’interno delle opzioni principali del core. Di seguito una breve panoramica sul loro funzionamento e utilizzo.

• (ParaLLEl-RDP) Upscaling factor (Restart)

Opzioni disponibili: 1x, 2x, 4x, 8x

Il fattore di upscaling per la risoluzione interna. 1x è l’impostazione predefinita ed è la risoluzione nativa. 2x, 4x e 8x sono comunque tutti possibili.

[stextbox id=’info’]Nota: Va sottolineato che 8x richiede almeno 5 GB/6 GB di VRAM sulla GPU. I requisiti di sistema sono piuttosto rigidi per 8x e in genere non viene consigliato nulla al di sotto di una 1080 Ti o superiore.[/stextbox]

Il percorso potrebbe variare, basta essere avvisato. 2x e 4x in confronto sono molto più leggeri. Anche durante l’upscaling, il rendering è ancora con la massima precisione e tutto il software viene ancora renderizzato sulla GPU. 4x upscale significa 16 volte il lavoro che 1x Angrylion avrebbe sfornato.

• (paraLLEl-RDP) Downsampling

Opzioni disponibili: Disable, 1/2, 1/4, 1/8

Conosciuto anche come SSAA, funziona in modo abbastanza simile alla funzione di downscaling di SSAA nel renderer Vulkan di Beetle PSX HW. L’idea è di eseguire l’upscaling interno ad una risoluzione più elevata, quindi impostare questa opzione da “Disable” a uno qualsiasi degli altri valori.

Quello che succede da lì è che questa immagine interna ad alta risoluzione viene poi ridotta a metà della sua dimensione, a un quarto della sua dimensione o a otto della sua dimensione.

Questo ti dà un’immagine anti-alias molto attenuata che a tutti gli effetti produce ancora 240p/240i. Da lì, puoi applicare alcuni shader frontend in alto per creare un aspetto molto piacevole e accattivante che sembra ancora migliore della risoluzione nativa ma è anche molto fedele ad esso.

Quindi, se desideri un upscaling con risoluzione 4x con 4x SSAA, imposta “Downsample” su 1/2. Con 4x upscale e 1/4 downsample, ottieni 240p di output con 16x SSAA, che si abbinano perfettamente agli shader CRT.

• (paraLLEl-RDP) Use native texture LOD when upscaling

Questa opzione è disabilitata di default.

Attualmente solo un gioco richiede l’attivazione di questa opzione. Se non attivo, la transizione tra Princess-to-Bowser in Mario 64 non sarà presente mentre invece si vede solo Bowser nel ritratto da lontano. Potrebbero esserci ulteriori miglioramenti in seguito per tentare di rilevare automaticamente questi casi.

La maggior parte dei giochi N64 non utilizzava il mipmapping, ma quelli che beneficiano in media di questa impostazione sono disattivati: ottieni texture LOD di qualità superiore invece di una texture LOD di qualità inferiore che alla fine si fa strada per una più dettagliata quando ti avvicini.

Tuttavia, attivare questa opzione potrebbe anche essere desiderabile a seconda che si preferisca una grafica dall’aspetto più accurato o un facsimile di come apparivano le cose un tempo.

• (paraLLEl-RDP) Use native resolution for TEX_RECT
  

Questa opzione è attiva per impostazione predefinita.

Gli elementi 2D come gli sprite sono di solito resi con comandi TEX_RECT e il tentativo di ingrandirli porta inevitabilmente a brutte “cuciture” nella foto. Questa opzione forza il rendering con risoluzione nativa per tali sprite.

Gestire le aspettative

Ora è importante che le persone capiscano qual’è l’obiettivo di questo renderer. Non c’è intenzione di avere ancora un altro renderer focalizzato sul miglioramento. Questo è il più vicino che ci sia mai stato fino ad oggi di un software completo resa come reimplementazione di Angrylion sulla GPU con ulteriori dettagli come l’upscaling. Il renderer garantisce la precisione dei bit, ciò che vedi è ciò che otterrai su di una console N64, senza eccezioni.

Con un renderer HLE, la scena viene renderizzata utilizzando le regole di rasterizzazione OpenGL o Vulkan. Qui, nessuno dei due viene eseguito: vengono seguite le esatte fasi di rasterizzazione dell’RDP, non ci sono chiamate API a GL per disegnare triangoli qui o là.

Quindi, come si fa? Tramite shader di calcolo, è stato stabilito che non è possibile emulare correttamente le regole di rasterizzazione del PSR semplicemente mappandolo su OpenGL. Questo è il motivo per cui i precedenti tentativi come z64gl sono falliti dopo un inizio promettente iniziale.

Quindi la proposta di valore qui per l’upscaling con ParaLLEl RDP è abbastanza convincente: ottieni l’upscaling con il renderer più accurato da questo lato di Angrylion.

Funziona bene grazie a Vulkan, puoi eseguire l’upscaling fino a 8x (che è un carico di lavoro folle per una GPU fatta in questo modo), e i puristi ottengono l’ulteriore soddisfazione di vedere per la prima volta l’upgrade della grafica N64 utilizzando l’intera pipeline di postelaborazione dell’N64 finalmente in azione per gentile concessione della VI Interface.

Ottieni un buon filtro di dithering che si attenua davvero bene a risoluzioni più elevate e può davvero fingere l’illusione di una maggiore profondità di bit. I renderer HLE hanno molti problemi con il tipo di tracciamento della profondità e il dithering applicati alla geometria, ma ParaLLEl RDP lo fa senza sforzo.

Ciò fa apparire meno sterile la grafica, mentre con la tradizionale rasterizzazione GL/Vulkan, vedresti le stesse texture ripetute ovunque con la stessa opacità di base ovunque. Qui, otteniamo il dithering e il filtro divot che creano ulteriore rumore all’immagine che porta a un’immagine complessivamente più ricca.

In sostanza, l’obiettivo qui è emulare effettivamente il PSR e il PSR. L’obiettivo non è far funzionare la maggior parte dei giochi commerciali e simulare l’output che genererebbero attraverso chiamate API di livello superiore.

Non sarà fatto – dove vince HLE

Pertanto, le seguenti richieste non saranno perseguite almeno nel prossimo futuro:

* Widescreen rendering – Può essere fatto tramite patch di gioco (patch ASM applicate direttamente sulla ROM, o patch bps/up o qualcosa di simile). Deve essere fatto in base al gioco, con HLE c’è un modo per modificare il frustum della vista e le dimensioni del viewport per farlo, ma non funziona quasi mai a causa del modo in cui il gioco occlude geometria e oggetti in base alla distanza, quindi le patch di gioco che implementano miglioramenti della distanza widescreen e DOF/draw sarebbero sempre preferibili.

Quindi, in breve, sì, puoi farlo anche con ParaLLEl RDP, solo con patch specifiche per gioco. Non aspettarti un’opzione di base che puoi semplicemente attivare o disattivare.

* Rendering di effetti framebuffer a una risoluzione più elevata – non è davvero possibile con LLE, non vedo nemmeno molto profitto. In teoria potrebbero essere possibili effetti di framebuffer super-campionati.

* Pacchetti di risoluzione delle texture – Ancora una volta, no. La natura di un renderer LLE è proprio lì nel nome, di basso livello. Mentre l’RDP sta elaborando flussi di dati (alimentati dall’RSP), non esiste quasi alcuna nozione di “texture”: vede solo caricamenti TMEM e descrittori di riquadri che puntano a byte non elaborati.

Con l’emulazione di alto livello, hai un livello di astrazione più elevato in cui puoi “agganciarti” alle parti in cui pensi che potrebbe essere in corso un caricamento di texture in modo da poterlo sostituire al volo.

Ad ogni modo, chi è alla ricerca di qualcosa del genere è in realtà all’indirizzo sbagliato con ParaLLEl RDP comunque. ParaLLEl RDP consiste nel rendere il rendering N64 autentico il più bello possibile senza ricorrere alla sostituzione di risorse originali o altro.

* Precisione Z-fighting/subpixel: in alcuni giochi, c’è un leggero Z-fighting in lontananza che potresti vedere quali rendering HLE in genere non hanno. Ancora una volta, questo perché si tratta di un’accurata emulazione RDP.

Z-fighting è una cosa. L’RDP ha solo UNORM a 18 bit di precisione di profondità con 10 bit di precisione frazionata durante l’interpolazione e una compressione superiore per comprimerlo fino a 14 bit.

Un emulatore HLE può eseguire il rendering a una profondità di oltre 24 bit. A comporre ciò, poiché l’RSP è di basso livello, sta inviando le coordinate del vertice a punto fisso a 16 bit all’RDP per il rendering.

Un tipico renderer HLE e HLE RSP determinerebbero solo che stiamo per disegnare una geometria 3D e poi la trasformeremo in valori float in modo che ci sia un livello più alto di precisione quando si tratta di posizionamento del vertice.

Se ricordi, anche il GTE di PlayStation1 non si occupava delle coordinate del vertice in float ma in virgola fissa. Lì, abbiamo dovuto impegnarci a fare PGXP per convertirlo in float. Dubito davvero che ci sia interesse a contemplarlo a questo punto. 

* Prestazioni grezze. HLE utilizza le unità di rasterizzazione hardware e texture della GPU che è molto più efficiente del software, ma ovviamente è molto meno preciso del rendering del software.

Dove vince LLE

Al contrario, ci sono parti in cui LLE vince su HLE e dove HLE non può davvero arrivare.

* HLE tende a lottare con le decalcomanie, il bias di profondità non emula affatto lo schema di bias di profondità del PSR poiché il bias di profondità del PSR è un test a doppia faccia. La distorsione da profondità è anche nota per comportarsi in modo diverso su GPU diverse.

* Dithering corretto. Un renderer HLE deve ancora lavorare con una pipeline di fusione a funzione fissa. Un software reso rasterizzatore come ParaLLEl RDP non deve funzionare con alcuna configurazione API grafica preesistente, implementa il proprio rasterizzatore e lo emette sullo schermo attraverso l’ombreggiatura del calcolo.

Il dithering corretto significa applicare il dithering dopo la fusione, tra le altre cose, che non è qualcosa che generalmente si può fare [con HLE]. In genere sembra un po’ scadente fare il dithering in OpenGL, è necessario un input a 8 bit ed eseguire la fusione in 8 bit ma alla fine dithering + quantizzazione, cosa che non è possibile eseguire nella fusione a funzioni fisse.

* L’intera pipeline di postelaborazione VI. Ancora una volta, vale la pena ripetere che non solo la grafica RDP viene ingrandita, ma anche il filtro VI. Il filtro VI ha avuto una cattiva reputazione sull’N64 perché questo MSAA quasi-8x eccessivo tenderebbe a rendere le immagini già a bassa risoluzione ancora più sfocate.

Ma a risoluzioni più elevate, come puoi vedere qui, può davvero brillare. Hai bisogno di una fusione programmabile per emulare la copertura del VI, e questo non è pratico con OpenGL e/o gli attuali renderer HLE.

Il VI ha un filtro abbastanza ingegnoso che distribuisce il rumore di dithering dove ricostruisce una maggiore profondità del colore. Quindi non solo stiamo ricevendo AA post-elaborazione per gentile concessione del PSR, ma stiamo anche ottenendo una maggiore intensità del colore.

* Quello che vedi è quello che ottieni. Questo renderer è l’ipotetico scenario di come apparirebbe un’unità N64 Pro in grado di pompare risoluzioni folli pur avendo lo stesso hardware.

Si noti che le implementazioni del PSR/VI in ParaLLEl RDP NON sono state migliorate in alcun modo. L’unica vera modifica è stata la modifica del rasterizzatore per testare anche le coordinate frazionarie dei pixel.

* Precisione totale con i readback della CPU. La CPU è in grado di leggere e scrivere liberamente su dati di rendering RDP e possiamo gestirla facilmente senza ulteriori hack.

Problemi noti

• Il processo di deinterlacciamento per le modalità video interlacciate è ancora piuttosto scarso (proprio come Angrylion), impostazione di base del bob e della texture. Ci sono piani per escogitare un sistema completamente nuovo.
• Mario Tennis è un po’ esagerato con l’upscaling per qualche motivo, potrebbero esserci dei bug sottili nell’implementazione che si manifestano solo in quel gioco. Questo sembra non accadere sui driver Windows Nvidia.

Schermate

Le schermate seguenti mostrano ParaLLEl RDP in esecuzione alla massima risoluzione di input interna, 8 volte l’immagine nativa originale. Ciò significa che quando il gioco è in esecuzione a 256×224, sarebbe in esecuzione a 2048×1792.

Ma se il tuo gioco funziona per dire a 640×480 (alcuni giochi interlacciati in realtà impostano una risoluzione così alta, Indiana Jones IIRC), allora saremmo a 5120×3840, che è più grande di una risoluzione 4K!

Quindi tieni presente che oltre a questo otterrai l’8A MSAA del VI e, probabilmente, puoi iniziare a immaginare quanto sia impegnativo questo sulla tua GPU dato che sta cercando di eseguire un rasterizzatore software personalizzato su hardware.

Basti dire che le richieste di 2x e 4x non saranno probabilmente troppo ripide, ma se stai pensando di usare 8x, è meglio portare un po’ di potenza GPU. Per iniziare, avrai bisogno di almeno 5-6 GB di VRAM per una risoluzione interna di 8x.

Ad ogni modo, senza ulteriori indugi, ecco alcuni screenshot gloriosi. GoldenEye 007 ora appare pericolosamente vicino alle immagini rialzate di bullshot sul retro del boxart!

Galleria video

Prossimamente su Mupen64Plus

ParaLLEl RDP si farà strada anche nella prossima nuova versione di Mupen64Plus Next. Aspettati una maggiore compatibilità con ParaLLEl N64 (soprattutto su Android) e prestazioni potenzialmente migliori in molti giochi.

Fonte: libretro.com