Il developer m4xw ha pubblicato un nuovo e interessantissimo aggiornamento per il core Libretro Mupen64Plus-Next con supporto per le API Vulkan e upscaling RDP di basso livello.

Una valida alternativa al core Libretro paraLLEl N64 che, anche se si dimostra superiore sotto certi aspetti, presenta una più ampia compatibilità.

The first builds are reaching the core downloader, so here is the changelog for Mupen64Plus-Next v2.1, including important informations https://t.co/KUsBPNdck7

— m4xw (@m4xwdev) June 27, 2020

Note per la versione Nintendo Switch di RetroArch

Con lo sviluppo del supporto del renderer threaded abbiamo notato alcuni problemi nei driver audio specifici della nostra piattaforma, in particolare audren_thread, che causerebbe il freeze casuale di alcuni core, molto spesso multithread. Esiste comunque una possibile soluzione, dimezzando l’attuale latenza audio.

Per il momento si consiglia di passare per il driver audio switch_thread, questo almeno fino a quando i problemi non saranno risolti.

Un altro core che presenta la stessa problematica è PPSSPP, se si verificano blocchi casuali, prova anche qui a passare per il driver audio switch_thread, l’unica cosa che perderai sarà l’audio nelle registrazioni in-game.

GlideN64

Questa nuova versione di Mupen64Plus-Next dovrebbe essere aggiornata con le versioni più recenti di GLideN64. Ecco alcuni punti salienti, che ora sono disponibili anche nel libretro-core.

Threaded Renderer

Ora esiste una nuova opzione che prende il nome di “Threaded Renderer” per il core Libretro, che se abilitato potrebbe aumentare considerevolmente le prestazioni, a scapito di una latenza di input leggermente superiore.

Per utilizzarlo, andare Command > Menu Toggle > Opzioni, assicuratevi di aver impostato “RDP Plugin” su “GLideN64” (l’impostazione non farà nulla con Angrylion e/o ParaLLEl RDP). Quindi attivare o disattivare “Threaded Renderer”, dopo la modifica, riavviare il core (chiudere il contenuto e caricare nuovamente la ROM con il core).

[stextbox id=’info’]Nota: Attualmente il passaggio di un gioco da schermo intero a finestra o viceversa con il Threaded Renderer attivato, blocca l’esecuzione della ROM (lo stesso vale anche per la modifica di Video Threaded in RetroArch).[/stextbox]

Benchmark

I test sono stati eseguiti su di un PC desktop Core i7 7700k con scheda grafica Geforce RTX 2080 Ti.

[stextbox id=’info’]Nota: Questi test sono stati eseguiti con hyper threading abilitato e throttling della CPU, quindi prendi queste cifre con cautela. La cosa più importante da togliere a questo è che VI/s è quasi 300 unità di misura più veloce con una risoluzione nativa da 2x a 4x rispetto al rendering senza thread in questo test.[/stextbox]

Questa funzione aiuterà in modo significativo piattaforme come Nintendo Switch e Raspberry Pi.

Dithering

In passato, i renderer HLE non hanno davvero tentato di implementare il dithering (ovviamente, con i renderer LLE RDP lo ottieni gratuitamente). Un gioco N64 viene in genere reso utilizzando un buffer di colore a 16 bit, e il dithering viene utilizzato per ridurre la fascia di colore e creare l’illusione di una maggiore profondità di colore. GLideN64 in passato ha sempre utilizzato il rendering a 32 bit.

Sono disponibili diverse opzioni principali:

• Dithering Pattern
• Dithering Quantization
• RDRAM Image Dithering Mode

Se usi la risoluzione nativa del N64, puoi anche abilitare un modello di Dithering per ottenere un aspetto più autentico, ma anche se ti piace giocare in HD, questo è qualcosa che vale la pena provare.

ParaLLEl RDP

Ormai hai sentito tutto sul rivoluzionario renderizzatore ParaLLEl RDP basato su Vulkan, che ha debuttato per primo in ParaLLEl N64. Ora è incluso per la prima volta in Mupen64Plus-Next.

Sono disponibili tutte le stesse funzionalità e altro ancora:

• La compatibilità su Android con ParaLLEl RDP dovrebbe essere più elevata ora a causa di aggiornamenti mirati del core mupen64plus. Giochi come Paper Mario, GoldenEye 007 e altri in precedenza si bloccavano su Android con ParaLLEl RDP+RSP.
• Le prestazioni dovrebbero essere circa il 5-10% più veloci in media rispetto al ParaLLEl N64. A volte anche un po’ di più.
• Alcuni problemi di compatibilità che si sono verificati anche su PC x86/x64 con ParaLLEl N64 non sono più un problema con Mupen64Plus-Next (come Perfect Dark che si bloccava all’avvio, problemi grafici di Pokemon Snap, Mario no Photopi non funziona, Bad Fur Day di Conker).

Nel tempo probabilmente riutilizzeremo ParaLLel N64 e lasceremo Mupen64Plus-Next al centro della scena.

Opzioni core migliorate

Aggiunte descrizioni delle etichette secondarie all’interno delle opzioni principali. Si spera che questo li renderà un po’ meno confuse. Da tenere presente che al momento non è possibile nascondere le opzioni al volo.

Bugfix e modifiche

• Android: Corretto il problema della spazzatura sul framebuffer con GLES3 (dove si troverebbe l’overscan).
• Android: Passa a “on Vertical Interrupt buffer swap mode” (potrebbe richiedere un po’ di perfezionamento) ma l’overlay touch era praticamente inutilizzabile con esso.
• Aggiornato Parallel-RSP.
  • Corretti alcuni problemi di stabilità in parallel-rsp su 64 bit.
• Aggiunta opzione core Native Resfactor (impostata su disabilitato / 0 per utilizzare le risoluzioni personalizzate come al solito).
  • Nota che con Native Resfactor l’opzione di risoluzione fungerà da dimensione della finestra.
• Aggiunta l’opzione Copy Aux to RDRAM core.
• Aggiunto uno script per rigenerare le intestazioni INI, aggiornato alle ultime varianti.
  • Nota: Sembra che avessi ancora trucchi per la correzione del sottoschermo OoT e lo spostamento osseo DK64 da quando ho scritto il core per la prima volta, questi hanno causato alcuni problemi dopo che è stato corretto nel core, quindi mi sono sbarazzato di loro per sempre, è stata una svista.
• Rimosso CountPerOp=1 per Quake 2 e Goldfinger.
  • Nota: Dopo aver parlato con alcune persone a monte, nessuno sa perché è stato persino costretto a 1, ha causato prestazioni paralizzanti su Android e Switch e dopo ore di test non è stato trovato nessun problema di gioco, in futuro potrei lavorare per sbarazzarmi di Count-Per-Op per sempre, è una brutta approssimazione.
• Consentito un conteggio per operazione più elevato.
• Nintendo Switch: Ridotti i requisiti di versione del firmware.
• Aggiunto supporto per il collegamento contro le librerie di sistema.
• Corretto il problema con il fallback di LLE che veniva considerato erroneamente supportato, corregge l’HLE di espansione in F-Zero X.
• Filtro ibrido esposto.

Queste correzioni sono incorporate in ParaLlEl N64 e Mupen64Plus-Next:

• I ritratti dei personaggi di Vigilante 8 non sono più erroneamente colorati.
• Lo schermo introduttivo di Mario Tennis non ha più tonnellate di bug grafici.

Differenze tra Mupen64Plus-Next e ParaLLEl N64

• ParaLLEl N64 ha i seguenti plugin RDP: Glide64, GLN64, Rice, Angrylion, ParaLLEl RDP. Glide64, GLN64 e Rice sono rivolti più alla fascia bassa delle schede grafiche.
• Mupen64Plus-Next ha i seguenti plugin RDP: GlideN64, Angrylion, ParaLLEl RDP. GLideN64 dovrebbe essere il renderer HLE RDP migliore della categoria, ma potrebbe avere prestazioni e requisiti GL più elevati rispetto al Gliden64/GLN64/Rice di fascia bassa di ParaLLEl N64.
• Sia ParaLLEl N64 che Mupen64Plus-Next hanno gli stessi plugin RSP (HLE, interprete LLE cxd4 e ParaLLEl RSP)
• ParaLLEl N64 utilizza Hacktarux dynarec per x86 32 bit/64 bit e new_dynarec per ARM. Mupen64Plus-Next utilizza invece new_dynarecs sia per architetture x86 che ARM, e di conseguenza tende ad essere un po’ più veloce.
• ParaLLEl N64 ha alcuni schemi di controllo alternativi specifici del gioco integrati che puoi accendere/spegnere con il pulsante SELECT. Mupen64Plus-Next non lo ha ancora.

Fonte: libretro.com